problem with 8-bit chars?

problem with 8-bit chars?

[Carlos Carvalho]

version 2.6-beta10-hzoli10.3 on linux

I tried "lpr curr@culo.lj", where the @ stands for the letter i with an
accute accent, and got "zsh: command not found: ulo.lj". Completion on
the filename works fine. To manage to print I had to put the filename
in single quotes :-(

Carlos

Re: problem with 8-bit chars?

[Zoltan Hidvegi]

Carlos Carvalho wrote:
> 
> version 2.6-beta10-hzoli10.3 on linux
> 
> I tried "lpr curr@culo.lj", where the @ stands for the letter i with an
> accute accent, and got "zsh: command not found: ulo.lj". Completion on
> the filename works fine. To manage to print I had to put the filename
> in single quotes :-(

I'll check this.  The problem is somewhere in zle, since zsh -c 'echo foo@bar'
works if @ is an accented letter.

Zoltan

Re: problem with 8-bit chars?

[Zoltan Hidvegi]

Carlos Carvalho wrote:
> 
> version 2.6-beta10-hzoli10.3 on linux
> 
> I tried "lpr curr@culo.lj", where the @ stands for the letter i with an
> accute accent, and got "zsh: command not found: ulo.lj". Completion on
> the filename works fine. To manage to print I had to put the filename
> in single quotes :-(
> 
> Carlos

The bug is in Peter's input patches.  It checks wether the character returned
by ingetc() is negative or not.  If it is negative, it thinks that it is an
error.  This only happens when history expansion is active, so single quotes
or the nobanghist option prevents this bug.  It can be fixed by some explicit
casts from signed  to unsigned characters, but I do not have time do play with
that now (it is very trivial to fix, but we shold be carefull not to break
comparison line c == HISTSPACE etc.)

Zoltan

Re: problem with 8-bit chars?

[P.Stephenson]

hzoli@cs.elte.hu wrote:
> Carlos Carvalho wrote:
> > 
> > version 2.6-beta10-hzoli10.3 on linux
> > 
> > I tried "lpr curr@culo.lj", where the @ stands for the letter i with an
> > accute accent, and got "zsh: command not found: ulo.lj". Completion on
> > the filename works fine. To manage to print I had to put the filename
> > in single quotes :-(
> > 
> > Carlos
> 
> The bug is in Peter's input patches.  It checks wether the character returned
> by ingetc() is negative or not.  If it is negative, it thinks that it is an
> error.  This only happens when history expansion is active, so single quotes
> or the nobanghist option prevents this bug.  It can be fixed by some explicit
> casts from signed  to unsigned characters, but I do not have time do play wit
> h
> that now (it is very trivial to fix, but we shold be carefull not to break
> comparison line c == HISTSPACE etc.)

1) I sent the reply by mistake just to Zoltan again.  I do that every
time I've been away from the keyboard for a while.

2) The following version is probably better anyway.  The previous
version passed a char to hwaddc() which could cause problems with K&R
compilers.  I think hwaddc() is the only place where HISTSPACE is
compared with a non-char, so casting the int to char here should be a
safe fix.  (I trust even K&R will distinguish been (i1 == i2) and
((char)i1 == (char)i2) ?)

*** Src/hist.c.us	Fri Sep 22 04:12:01 1995
--- Src/hist.c	Fri Oct  6 08:48:51 1995
***************
*** 41,47 ****
  void
  hwaddc(int c)
  {
!     if (hlastw && chline && (!(errflag || lexstop) || c == HISTSPACE)) {
  	if (c == bangchar && unset(NOBANGHIST))
  	    hwaddc('\\');
  	*hptr++ = c;
--- 41,47 ----
  void
  hwaddc(int c)
  {
!     if (hlastw && chline && (!(errflag || lexstop) || (char)c == HISTSPACE)) {
  	if (c == bangchar && unset(NOBANGHIST))
  	    hwaddc('\\');
  	*hptr++ = c;
*** Src/input.c.us	Fri Sep 22 04:12:06 1995
--- Src/input.c	Thu Oct  5 08:31:51 1995
***************
*** 109,115 ****
  	if (inbufleft) {
  	    inbufleft--;
  	    inbufct--;
! 	    return lastc = *inbufptr++;
  	}
  	/*
  	 * No characters in input buffer.
--- 109,115 ----
  	if (inbufleft) {
  	    inbufleft--;
  	    inbufct--;
! 	    return lastc = (int)(unsigned char)*inbufptr++;
  	}
  	/*
  	 * No characters in input buffer.


-- 
Peter Stephenson <P.Stephenson@swansea.ac.uk>  Tel: +44 1792 205678 extn. 4461
WWW:  http://python.swan.ac.uk/~pypeters/      Fax: +44 1792 295324
Department of Physics, University of Wales, Swansea,
Singleton Park, Swansea, SA2 8PP, U.K.

Re: problem with 8-bit chars?

[Vinnie Shelton]

In message <8075.9510061512@pygmy.swan.ac.uk>, P.Stephenson@swansea.ac.uk wrote:
>1) I sent the reply by mistake just to Zoltan again.  I do that every
>time I've been away from the keyboard for a while.

Richard, can we please fix this?  I would much rather see replies default
go to the entire list.

Vin

Re: problem with 8-bit chars?

[Mark Borges]

>> On Fri, 06 Oct 1995 11:54:30 -0400,
>> Vinnie Shelton(V) wrote:
V> In message <8075.9510061512@pygmy.swan.ac.uk>,
V> P.Stephenson@swansea.ac.uk wrote:

>> 1) I sent the reply by mistake just to Zoltan again.  I do that every
>> time I've been away from the keyboard for a while.

V> Richard, can we please fix this?  I would much rather see replies default
V> go to the entire list.

I have to say that I hated this at first, too, but now I think it
makes some sense.

Doesn't your mail reader make a distinction between `reply' and
`follow-up'? I use VM, which does, and replies go only to the author,
while follow-ups go to all recipients. VM also makes it easy to filter
yourself out of the latter operation. Of course, this latter operation
could also send duplicates to those on the list not using procmail.

Or is Peter saying that the problem is that this behavior is not like
most (is that true?) other mail lists (where replies do go to the
list)? So he subconsciously reaches for the reply button because it's
habitual.

Anyway, I think this distinction is useful, but it's not a
make-or-break thing for me. I guess I tried to add 2 cents, but it
wound up being 1/20th of 1 cent. :-).

  -mb-

reply behavoir for zsh's mailing lists

[Richard Coleman]

> >1) I sent the reply by mistake just to Zoltan again.  I do that every
> >time I've been away from the keyboard for a while.
> 
> Richard, can we please fix this?  I would much rather see replies default
> go to the entire list.

I must say that personally I wouldn't mind that default replies go to
the list.  But there is actually another reason for not doing this.
Some (broken) auto-reply programs will actually remove some of the mail
headers when they send an automatic reply.  If it removes the X-loop
line, then SmartList (mailing list manager I use) has no way of detecting
a loop and hence sends it out to the list.  This cascading action of
mail messages would crash my mail server before I even knew anything
was happening.  Since many people are now using auto-reply programs
and mail robots, I think I should play it safe.

This was recently discussed on the SmartList mailing list and the
consensus seems to be that having default replies go to the list is
asking for disaster.

Richard Coleman
coleman@math.gatech.edu

Re: problem with 8-bit chars?

[Carlos Carvalho]

The hist.c hunk of Peter's patch is rejected. I applied it by hand and
the bug is fixed.

Carlos

Re: problem with 8-bit chars?

[Joachim Reith]

Hi

I have tried the same but on my system it's
working fine. Possibly is the difference the
system we're working on?
My version is 2.6-beta9 on a French-German
SCO OpenServer 5.0


frosch@doc2> lpr hh@hh
Anforderungskennung ist eng_lw3-17 (1 Datei)

("@" is the special character (german umlaut).
reporter output on request, it's just to long.)

|>
|>Carlos Carvalho wrote:
|>> 
|>> version 2.6-beta10-hzoli10.3 on linux
|>> 
|>> I tried "lpr curr@culo.lj", where the @ stands for the letter i 
with an
|>> accute accent, and got "zsh: command not found: ulo.lj". 
Completion on
|>> the filename works fine. To manage to print I had to put the 
filename
|>> in single quotes :-(
|>
|>I'll check this.  The problem is somewhere in zle, since zsh -c 
'echo foo@bar'
|>works if @ is an accented letter.
|>
|>Zoltan
|>

Re: problem with 8-bit chars?

[Zoltan Hidvegi]

> 
> Hi
> 
> I have tried the same but on my system it's
> working fine. Possibly is the difference the
> system we're working on?
> My version is 2.6-beta9 on a French-German
> SCO OpenServer 5.0
> 
> 
> frosch@doc2> lpr hh@hh
> Anforderungskennung ist eng_lw3-17 (1 Datei)
> 
> ("@" is the special character (german umlaut).
> reporter output on request, it's just to long.)


Do not send reporter output.  The problem seems to be beta10 or
beta10-hzoli10.3 specific.  And I think it was not me who introduced this,
since beta6-hzoli6 dosen't has this bug (that's the letest version older that
beta10 here).

Zoltan