HISTCHARS

HISTCHARS

[Barton E. Schaefer]

Somebody remind me why this has become a lower-case variable, and why it is
not mirrored to/from the upper-case version?

Does anybody know what the comprehensive list of these seemingly arbitrary
incompatibilities is?  I'm getting really tired of tweaking and re-tweaking
my .zsh* files every time I find another of these stupid things.  We need a
complete upgrade guide of some sort.

zyrcon[27] echo $HISTCHARS
!=#
zyrcon[28] echo foo bar
foo bar
zyrcon[29] =foo=bar
zsh: foo not found
zyrcon[25] zsh-2.3.100
zyrcon<1> echo $HISTCHARS
!=#
zyrcon<2> echo foo bar
foo bar
zyrcon<3> =foo=bar
echo bar bar
bar bar
zyrcon<4> zsh-2.5.01
zyrcon<1> echo $HISTCHARS
!=#
zyrcon<2> echo foo bar
foo bar
zyrcon<3> =foo=bar
echo bar bar
bar bar
zyrcon<4>



-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                  Division of NCD Software Corporation
http://www.well.com/www/barts           http://www.ncdsoft.com/ZMail/

Re: HISTCHARS

[Zoltan Hidvegi]

> Somebody remind me why this has become a lower-case variable, and why it is
> not mirrored to/from the upper-case version?
> 
> Does anybody know what the comprehensive list of these seemingly arbitrary
> incompatibilities is?  I'm getting really tired of tweaking and re-tweaking
> my .zsh* files every time I find another of these stupid things.  We need a
> complete upgrade guide of some sort.

HISTCHARS was changed to histchars quite long ago because both bash and csh
use the lower-case version.

A complete list of changes would be useful indeed.  There is a NEWS file
listing the new features in zsh-2.5 (strange that some of these features
were completely unusable in 2.5 because of the bugs).  Perhaps it the
upgrage guite should go there.  An other difference which comes to my mind
is the ${~...} ${^...} and ${=...} parameter substitution syntax, which do
not toggle the relevant options anymore.  Also GLOB_SUBST and ${~...} do
not evaluate the substituted parameter expansions:

% foo='$bar' ; echo $~foo
$bar

instead of printing the value of bar (but ${(e)foo} can be use for that).


% foo=*

does not glob.  Use foo=( * ).

An other change is "${#foo}" gives the array length if foo is an array (use
"${(c)#foo}" to get the old behaviour).  It also caused problems that
PROMPT_SUBST now really works and expads backquote substitutions (it didn't
do that before beta17).  Also history expansion is disabled in single
quoted strings.  This may break some functions which used something like
sed '/pattern/\!d' since now the backslash is passed to sed.

There are probably many other changes I forgot (I did not use 2.5 too much
since it was too buggy, and 2.5 was the first zsh version I ever used).

Zoltan

Re: HISTCHARS

[Richard Coleman]

> > Somebody remind me why this has become a lower-case variable, and why it is
> > not mirrored to/from the upper-case version?
> > 
> > Does anybody know what the comprehensive list of these seemingly arbitrary
> > incompatibilities is?  I'm getting really tired of tweaking and re-tweaking
> > my .zsh* files every time I find another of these stupid things.  We need a
> > complete upgrade guide of some sort.
> 
> HISTCHARS was changed to histchars quite long ago because both bash and csh
> use the lower-case version.

Yes, I made that change.  And I've since come to regret it.  I had planned
on changing it back, but was procrastinating since I'm sure lots of people
would raise hell.

I think it makes more sense for it to be HISTCHARS, since this is consistent
with the case of HISTFILE and HISTSIZE.  I now believe this to be more
important than compatibility with base or csh.

I would suggest we change it back before the release of 3.0.

rc

Re: HISTCHARS

[Zoltan Hidvegi]

> > HISTCHARS was changed to histchars quite long ago because both bash and csh
> > use the lower-case version.
> 
> Yes, I made that change.  And I've since come to regret it.  I had planned
> on changing it back, but was procrastinating since I'm sure lots of people
> would raise hell.
> 
> I think it makes more sense for it to be HISTCHARS, since this is consistent
> with the case of HISTFILE and HISTSIZE.  I now believe this to be more
> important than compatibility with bash or csh.

I think that presently much more people use bash than zsh, especially
because all Linux distributions come with bash as the default login shell.
It is easier to convince these people about the superiority of zsh if we
provide better compatibility.  And probably even more people use csh or
tcsh out there.

Zoltan

Re: HISTCHARS

[Barton E. Schaefer]

On May 23,  2:48pm, Richard Coleman wrote:
} Subject: Re: HISTCHARS
}
} I think it makes more sense for it to be HISTCHARS, since this is consistent
} with the case of HISTFILE and HISTSIZE.  I now believe this to be more
} important than compatibility with base or csh.

Why not just mirror histchars/HISTCHARS, as with cdpath/CDPATH et. al.?

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                  Division of NCD Software Corporation
http://www.well.com/www/barts           http://www.ncdsoft.com/ZMail/

Re: HISTCHARS

[Richard Coleman]

> > I think it makes more sense for it to be HISTCHARS, since this is consistent
> > with the case of HISTFILE and HISTSIZE.  I now believe this to be more
> > important than compatibility with bash or csh.
> 
> I think that presently much more people use bash than zsh, especially
> because all Linux distributions come with bash as the default login shell.
> It is easier to convince these people about the superiority of zsh if we
> provide better compatibility.  And probably even more people use csh or
> tcsh out there.
> 
> Zoltan
> 

Yes, but compability has its limits.  It's fine if zsh is compatible
with ksh (and sh).  But when we try to make zsh compatible with every
shells (by also worrying about csh, tcsh and bash compatibility), it
starts to get too unwieldy.  No shell can do everything.  The art is in
picking the correct set of compromises.

rc

Re: HISTCHARS

[Zoltan Hidvegi]

> On May 23,  2:48pm, Richard Coleman wrote:
> } Subject: Re: HISTCHARS
> }
> } I think it makes more sense for it to be HISTCHARS, since this is consistent
> } with the case of HISTFILE and HISTSIZE.  I now believe this to be more
> } important than compatibility with base or csh.
> 
> Why not just mirror histchars/HISTCHARS, as with cdpath/CDPATH et. al.?

It is desirable to minimize the number of special parameters sice it is
quite difficult to handle special parameters in some cases.  It can be
arranged that HISTCHARS will only work if zsh is not called as sh/ksh but
is it really necessary?  HISTCHARS did not even work originally since in
many places in the source ! was used explicitely instead of bangchar (but
it worked for hashchar I know).

Zoltan

Re: HISTCHARS

[Barton E. Schaefer]

On May 23,  9:36pm, Zoltan Hidvegi wrote:
} Subject: Re: HISTCHARS
}
} > Why not just mirror histchars/HISTCHARS, as with cdpath/CDPATH et. al.?
} 
} It is desirable to minimize the number of special parameters sice it is
} quite difficult to handle special parameters in some cases.  It can be
} arranged that HISTCHARS will only work if zsh is not called as sh/ksh but
} is it really necessary?

If it *has* to be limited that way, it's probably not worth the effort.

} HISTCHARS did not even work originally since in
} many places in the source ! was used explicitely instead of bangchar (but
} it worked for hashchar I know).

It also worked for the quick-history character, which is what's important
to me.

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                  Division of NCD Software Corporation
http://www.well.com/www/barts           http://www.ncdsoft.com/ZMail/

Re: HISTCHARS

[Zoltan Hidvegi]

> On May 23,  9:36pm, Zoltan Hidvegi wrote:
> } It is desirable to minimize the number of special parameters sice it is
> } quite difficult to handle special parameters in some cases.  It can be
> } arranged that HISTCHARS will only work if zsh is not called as sh/ksh but
> } is it really necessary?
> 
> If it *has* to be limited that way, it's probably not worth the effort.

It would not require any extra effort.  There are already several special
parameters which only work if zsh is not invoked as sh/ksh.  These are
ARGC, status, prompt, PROMPT, prompt2, prompt3, prompt4 and argv.  All of
these are just aliases for other parameters.  Adding HISTCHARS would require
one extra line in hashtable.h.

Zoltan

Re: HISTCHARS

[Vinnie Shelton]

Jeez Bart, where were you when I squawked about this originally?
FWIW, I agree w/ you.  It would probably be best to accept both histchars
and HISTCHARS.

In message <960523124342.ZM15962@zyrcon.z-code.com>, "Barton E. Schaefer" wrote
>It also worked for the quick-history character, which is what's important
>to me.

Ditto.

My $.02.

--vin

Re: HISTCHARS

[Barton E. Schaefer]

On May 23,  8:32pm, Zoltan Hidvegi wrote:
} Subject: Re: HISTCHARS
}
} A complete list of changes would be useful indeed.

The ones that I know of that make a difference to my zsh init files are
listed below.  The version number at left is the earliest I know of
where the change showed up.  I haven't tracked betas regularly since
sometime during 2.4 development, so I don't know the patch levels where
a lot of these showed up.  Changes in features I don't use, aren't here.

2.1:		Format of VERSION numbers changed from "X.0Y" to "X.Y".
		Beta versions became "X.Ybeta Z".

2.4:		Format of VERSION numbers changed from "X.Ybeta Z" to
		"X.Y.Z beta".  Broke all my carefully constructed tests,
		created in .zshrc as I upgraded through 2.2 and dozens
		of 2.3betas, for how a given zsh would behave.

2.5:		Format of VERSION numbers changed from "X.Y" to "X.Y.ZZ".
		At least this was relatively benign.

2.6:		First, VERSION numbers changed from "X.Y.Z beta" to
		"X.Y-betaZ".  Next, VERSION variable became ZSH_NAME
		and ZSH_VERSION.  Broke all my tests *twice*.  Make
		up your minds, willya?

2.5:		${1}${2:+="$argv[2,$#]"} broke; something about the `='.
		Intent is with argv=(foo bar baz), expand to foo="bar baz".

2.6:		HOSTTYPE iris4d became irix?? where ?? is OS version.
		Did other HOSTTYPEs change, too?  I haven't compiled 2.6
		on any other platforms yet, except Linux, for which I
		have no earlier examples.

2.2:		HISTCHARS="\!=#" broke; had to change to HISTCHARS="!=#".

2.6:		HISTCHARS became histchars.

2.1:		A whole bunch of new setopts:
		    KSH_OPTION_PRINT SUN_KEYBOARD_HACK PATHDIRS NOHUP
		    AUTO_MENU AUTO_REMOVE_SLASH
		Previously (2.00) I'd just used MENU_COMPLETE.

2.5:		CSH_JUNKIE_PAREN showed up, CSH_JUNKIE_TILDE went away.
		This wouldn't have been a problem if CSH_JUNKIE_PAREN
		had been *set* by default, rather than *un*set, but as
		it was it broke every .zshrc in our entire organization.
		We now setopt CSH_JUNKIE_PAREN in /etc/zshenv.

2.4:		New options COMPLETE_IN_WORD ALWAYS_TO_END AUTO_PARAM_KEYS.
		Zle gained push-line-or-edit.

2.6:		Backslash handling in prompts and in `print -P` changed.

2.4:		Namedirs got really stupid, and stayed stupid up to 2.5.
		Second-most annoying change ever.

2.5:		Option AUTO_NAME_DIRS fixed 2.4.  Huge sigh of relief.

2.1:		Prompt format %c started displaying too much of the path.

2.2:		Prompt format %c got a number suffix to limit the number
		of path components displayed.

2.3beta 90:	Prompt format sequence %c2 changed to %2c (number suffix
		became infix).

A couple of other changes that I recall are that SHLVL doesn't act the way
it used to (but I don't remember when that changed), and that "exec" causes
history files to be written (which I *really* can't stand).  I believe the
SHLVL thing is "exec"-related too, come to think of it.

Something else changed between 2.3 and 2.5 that confused a bunch of scripts
we use here, forcing me to leave 2.3 installed on several machines just to
be able to run those scripts ... but I don't remember what it was.  If I
figure it out I'll say something.

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
schaefer@z-code.com                  Division of NCD Software Corporation
http://www.well.com/www/barts           http://www.ncdsoft.com/ZMail/

Re: HISTCHARS

[Zoltan Hidvegi]

> 2.6:		First, VERSION numbers changed from "X.Y.Z beta" to
> 		"X.Y-betaZ".  Next, VERSION variable became ZSH_NAME
> 		and ZSH_VERSION.  Broke all my tests *twice*.  Make
> 		up your minds, willya?

I plan to call the next stable line as 3.0.X and the next beta line to
3.1.X.

> 2.6:		HOSTTYPE iris4d became irix?? where ?? is OS version.
> 		Did other HOSTTYPEs change, too?  I haven't compiled 2.6
> 		on any other platforms yet, except Linux, for which I
> 		have no earlier examples.

HOSTTYPE is obsolate.  There is $MACHTYPE $VENDOR $OSTYPE instead.  This
comes from GNU autoconf.

> 2.2:		HISTCHARS="\!=#" broke; had to change to HISTCHARS="!=#".

"\!=# still works.  You probably wanted to write '\!=#'.  I mentioned this
change in my previous mail.

> 2.5:		CSH_JUNKIE_PAREN showed up, CSH_JUNKIE_TILDE went away.
> 		This wouldn't have been a problem if CSH_JUNKIE_PAREN
> 		had been *set* by default, rather than *un*set, but as
> 		it was it broke every .zshrc in our entire organization.
> 		We now setopt CSH_JUNKIE_PAREN in /etc/zshenv.

That's because sh compatibility has higher preference now.

> A couple of other changes that I recall are that SHLVL doesn't act the way
> it used to (but I don't remember when that changed), and that "exec" causes
> history files to be written (which I *really* can't stand).  I believe the
> SHLVL thing is "exec"-related too, come to think of it.

Yes, SHLVL is exec related.  Again it is for better sh compatibility.

For exec, you can now alias exec to 'unset HISTFILE ; exec'.

>From what you describe it turns out that zsh was under heavy development.
2.5 was still very buggy.  I hope that zsh now stabilized a bit by now.

Zoltan

Re: HISTCHARS

[Bart Schaefer]

On May 23, 11:00pm, Zoltan Hidvegi wrote:
} Subject: Re: HISTCHARS
}
} > 2.6:		HOSTTYPE iris4d became irix?? where ?? is OS version.
} 
} HOSTTYPE is obsolate.

Why does it still exist, then?  If it's not going to have the same values
it used to have, it's pretty useless for it to even still be there.  I'd
rather have references to obsolete stuff produce an error than have it
silently do the wrong thing.

} There is $MACHTYPE $VENDOR $OSTYPE instead.  This
} comes from GNU autoconf.

Gag.  Oh, well.

} > 2.2:	HISTCHARS="\!=#" broke; had to change to HISTCHARS="!=#".
} 
} "\!=# still works.  You probably wanted to write '\!=#'.  I mentioned this
} change in my previous mail.

I wrote what I wanted to write.

"\!=#" behaves differently in an init file than in an interactive shell:

zagzig% cat .zshrc
HISTCHARS="\!=#"
zagzig% echo "$HISTCHARS"
\!=#
zagzig% HISTCHARS="\!=#"
zagzig% echo "$HISTCHARS"
!=#
zagzig%

This difference is pretty annoying, actually.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"

Re: histchars

[Bart Schaefer]

On Nov 29, 10:53am, Clint Adams wrote:
} Subject: Re: histchars
}
} > Hm.  No offense, but ... do you guys always change anything that anybody
} > submits a bug report for?
} 
} No.  Do you disagree with the decision?

You yourself said you didn't know why it was necessary.  The ChangeLog file
has these two entries from the same date:

Wed Jul 31 19:10:04 1996  Zoltan Hidvegi  <hzoli@cs.elte.hu>

        * Src/version.h: zsh-3.0-pre5 released

        * Src/hashtable.h, Src/params.c, Src/zsh.h: {E,}{U,G}ID, USERNAME,
          histchars, HISTCHARS, IFS are not imported

Since those variables were imported prior to 3.0, and that was deliberately
changed a year and a half ago, and nobody's complained to zsh-workers about
it in all that time, I tend to think that it ought to be left alone -- at
least until you know why it could be considered a bug.  (Perhaps for bash
or ksh behavior equivalence?)

I'd actually prefer it if *fewer* variables, rather than more, were imported
when shells start up.  It was fine when there were essentially two shells (sh
and csh) that shared no special variables; but now there are a dozen or more
sharing the same namespace.  For example, there are about three shells with
incompatible formats for PS1; it's annoying when zsh imports bash's prompt.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: histchars

[Clint Adams]

> Hm.  No offense, but ... do you guys always change anything that anybody
> submits a bug report for?

No.  Do you disagree with the decision?

Re: histchars

[Bart Schaefer]

On Nov 28,  2:34pm, Clint Adams wrote:
} Subject: Re: histchars
}
} > Uh, why?
} 
} I can't imagine why either, but this person seems to have a use for it:

Hm.  No offense, but ... do you guys always change anything that anybody
submits a bug report for?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: histchars

[Clint Adams]

> Uh, why?

I can't imagine why either, but this person seems to have a use for it:

(Debian GNU/Linux bug #6236)
From: JR Oldroyd <jr@hautbrion.terra.net>
Subject: BUG zsh $histchars

Package: zsh
Version: 3.0.2-1
It seems that $HISTCHARS is being reset by the shell when the
shell starts up.  This should not be happening.

        -jr

Re: histchars

[Bart Schaefer]

On Nov 28, 12:55pm, Clint Adams wrote:
} Subject: histchars
}
} This disables the resetting of HISTCHARS/histchars in zsh 3.0.5.

Uh, why?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

histchars

[Clint Adams]

This disables the resetting of HISTCHARS/histchars in zsh 3.0.5.


*** Src/hashtable.h.old	Fri Nov 28 12:37:13 1997
--- Src/hashtable.h	Fri Nov 28 00:28:46 1997
***************
*** 106,112 ****
  #define IPDEF2(A,B,C,D) {NULL,A,PM_SCALAR|PM_SPECIAL|D,BR(NULL),BR(C),BR(B),0,NULL,NULL,NULL,NULL,0}
  IPDEF2("USERNAME", usernamegetfn, usernamesetfn, PM_DONTIMPORT),
  IPDEF2("-", dashgetfn, nullsetfn, PM_READONLY),
! IPDEF2("histchars", histcharsgetfn, histcharssetfn, PM_DONTIMPORT),
  IPDEF2("HOME", homegetfn, homesetfn, 0),
  IPDEF2("TERM", termgetfn, termsetfn, 0),
  IPDEF2("WORDCHARS", wordcharsgetfn, wordcharssetfn, 0),
--- 106,112 ----
  #define IPDEF2(A,B,C,D) {NULL,A,PM_SCALAR|PM_SPECIAL|D,BR(NULL),BR(C),BR(B),0,NULL,NULL,NULL,NULL,0}
  IPDEF2("USERNAME", usernamegetfn, usernamesetfn, PM_DONTIMPORT),
  IPDEF2("-", dashgetfn, nullsetfn, PM_READONLY),
! IPDEF2("histchars", histcharsgetfn, histcharssetfn, 0),
  IPDEF2("HOME", homegetfn, homesetfn, 0),
  IPDEF2("TERM", termgetfn, termsetfn, 0),
  IPDEF2("WORDCHARS", wordcharsgetfn, wordcharssetfn, 0),
***************
*** 179,185 ****
  /* The following parameters are not avaible in sh/ksh compatibility *
   * mode. All of these has sh compatible equivalents.                */
  IPDEF1("ARGC", poundgetfn, nullsetfn, PM_READONLY),
! IPDEF2("HISTCHARS", histcharsgetfn, histcharssetfn, PM_DONTIMPORT),
  IPDEF4("status", &lastval),
  IPDEF7("prompt", &prompt),
  IPDEF7("PROMPT", &prompt),
--- 179,185 ----
  /* The following parameters are not avaible in sh/ksh compatibility *
   * mode. All of these has sh compatible equivalents.                */
  IPDEF1("ARGC", poundgetfn, nullsetfn, PM_READONLY),
! IPDEF2("HISTCHARS", histcharsgetfn, histcharssetfn, 0),
  IPDEF4("status", &lastval),
  IPDEF7("prompt", &prompt),
  IPDEF7("PROMPT", &prompt),