zsh 5.0.7

zsh 5.0.7

[Ray Andrews]

All,

I installed the latest 5.0.7 and it seems to have made two copies of 
itself in /usr/local/bin:

     -rwxr-xr-x 2 693K 2014-10-11//11:07:41 zsh-5.0.7*
     -rwxr-xr-x 2 693K 2014-10-11//11:07:41 zsh*

But even after a reboot:

     $ zsh --version
     zsh 5.0.6 (i586-pc-linux-gnu)

This in spite of "VERSION=5.0.7" in the sources.

Following the pointers:

/usr/bin/zsh ends up being /bin/zsh5, which seems to be the '5.0.6' version.

It sounds easy to fix, but I wonder what I did wrong.

Re: zsh 5.0.7

[Bart Schaefer]

On Oct 11, 11:53am, Ray Andrews wrote:
}
} I installed the latest 5.0.7 and it seems to have made two copies of 
} itself in /usr/local/bin:
} 
}      -rwxr-xr-x 2 693K 2014-10-11//11:07:41 zsh-5.0.7*
}      -rwxr-xr-x 2 693K 2014-10-11//11:07:41 zsh*

Not two copies, note the link count of 2.  Two hardlinks to the same file.

} But even after a reboot:
} 
}      $ zsh --version
}      zsh 5.0.6 (i586-pc-linux-gnu)
} 
} This in spite of "VERSION=5.0.7" in the sources.

That just means there's another $^path/zsh before /usr/local/bin/zsh.

} Following the pointers:
} 
} /usr/bin/zsh ends up being /bin/zsh5, which seems to be the '5.0.6' version.

That was probably installed by your OS distribution.

} It sounds easy to fix, but I wonder what I did wrong.

You didn't do anything wrong; zsh's default install is designed to avoid
stepping on files from the OS that may be under control of a package
manager.

Re: zsh 5.0.7

[Ray Andrews]

On 10/11/2014 01:10 PM, Bart Schaefer wrote:

Bart,
> Not two copies, note the link count of 2.  Two hardlinks to the same file.
Ah.  I've never paid any attention to hard links before, they aren't on 
my radar. Thanks.
> You didn't do anything wrong; zsh's default install is designed to avoid
> stepping on files from the OS that may be under control of a package
> manager.
>
Ok, so what's the approved fix? In this particular install I have no 
need to keep anything
around that's not current, and of course I want all roads to lead to 
5.0.7.  Should I just fiddle
with the pointers?

BTW, there doesn't seem to be anything else lying around that's 
obviously 5.0.6,
maybe Debian has it filed some other way. Nice to clean it out if 
possible but I don't want system
upgrades to get all flustered.

Re: zsh 5.0.7

[Axel Beckert]

Hi,

On Sat, Oct 11, 2014 at 02:46:50PM -0700, Ray Andrews wrote:
> On 10/11/2014 01:10 PM, Bart Schaefer wrote:
> BTW, there doesn't seem to be anything else lying around that's
> obviously 5.0.6,
> maybe Debian has it filed some other way.

JFYI:

Debian Testing and Unstable currently do have 5.0.6.

5.0.7 is available in Debian Experimental only currently.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@deuxchevaux.org  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: zsh 5.0.7

[Ray Andrews]

On 10/11/2014 02:56 PM, Axel Beckert wrote:
> Debian Testing and Unstable currently do have 5.0.6. 
I know, it upgraded itself just recently.  But I'm trying to install from

http://www.zsh.org/pub/

I  guess like most Debianites, I'm a bit slow learning how to do these 
things by hand.

Re: zsh 5.0.7

[Bart Schaefer]

On Oct 11,  2:46pm, Ray Andrews wrote:
}
} Ok, so what's the approved fix? In this particular install I have no
} need to keep anything around that's not current, and of course I want
} all roads to lead to 5.0.7. Should I just fiddle with the pointers?

You have several choices.

Firstly, you need to see if chsh will let you set your login shell to
/usr/local/bin/zsh.  If it won't, you can either --

1. find out which path actually is your login shell and link that path
   to /usr/local/bin/zsh, or (if that would fluster your upgrades)

2. try editing the file /etc/shells to add /usr/local/bin/zsh and then
   run chsh again, or

3. set up your login shell init to "exec /usr/local/bin/zsh" in the
   appropriate circumstances.

See FAQ "I don't have root access: how do I make zsh my login shell?"
for discussion of that last.

Once you get zsh going as your login shell, you need to change the
order of directories in the $path array to put /usr/local/bin near
the front.  If you can't do that for some other reason, you're back
to option (1) above.

You can also try to use your package manager to find out what installed
/usr/bin/zsh{,5} and remove that package.  Once you have done so, you
can rerun configure in your zsh build to set --exec-prefix=/usr and
then rebuild and install, but it'd probably be wiser to get it running
out of /usr/local if you can.

Re: zsh 5.0.7

[Ray Andrews]

On 10/11/2014 03:01 PM, Bart Schaefer wrote:
> On Oct 11,  2:46pm, Ray Andrews wrote:
> }
> } Ok, so what's the approved fix? In this particular install I have no
> } need to keep anything around that's not current, and of course I want
> } all roads to lead to 5.0.7. Should I just fiddle with the pointers?
>
> You have several choices.
>
> Firstly, you need to see if chsh will let you set your login shell to
> /usr/local/bin/zsh.  If it won't, you can either --
> 2. try editing the file /etc/shells to add /usr/local/bin/zsh and then
>     run chsh again, or

The horror: I got the dread: "PAM: Authentication failure". Tried to edit /etc/shells, no luck, tried to edit /etc/passwd and ended up being unable to log in at all.  Restored a backup.

> 1. find out which path actually is your login shell and link that path
>     to /usr/local/bin/zsh, or (if that would fluster your upgrades)
I ended up changing the 'zsh*' links in  '/etc/alternatives/' from 
'/bin/zsh5' to '/usr/local/bin/zsh'
and that seems to be working fine.

BTW, doing all of this as root.
> 3. set up your login shell init to "exec /usr/local/bin/zsh" in the
>     appropriate circumstances.
>
> See FAQ "I don't have root access: how do I make zsh my login shell?"
> for discussion of that last.
>
> Once you get zsh going as your login shell, you need to change the
> order of directories in the $path array to put /usr/local/bin near
> the front.  If you can't do that for some other reason, you're back
> to option (1) above.
I read something once that said '/usr/local/bin' should be at the end of 
the path.  It explained
how your system was in mortal peril otherwise.  Nevermind, I always 
thought it should come
first myself.
> You can also try to use your package manager to find out what installed
> /usr/bin/zsh{,5} and remove that package.  Once you have done so, you
> can rerun configure in your zsh build to set --exec-prefix=/usr and
> then rebuild and install, but it'd probably be wiser to get it running
> out of /usr/local if you can.
I see what you mean about not overwriting any packaged files, they are 
all different. I guess
that means I should now be able to purge zsh and Debian will just remove 
it's stuff, leaving
what I just installed alone.  But I'll make sure what I have now is 
stable, before I tinker
anymore.

Thanks Bart.

Re: zsh 5.0.7

[Greg Klanderman]

Hi Ray, on Debian, I build/install zsh as normal (not setting any
prefix path options, let it install in /usr/local/bin/zsh) then do
this:

update-alternatives --install /bin/zsh zsh /usr/local/bin/zsh 100 \
          --slave /usr/bin/zsh zsh-usrbin /usr/local/bin/zsh

and it will have /bin/zsh and /usr/bin/zsh point to your locally built
ones instead of the Debian provided packaged ones.

i.e. /bin/zsh will be a link to /etc/alternatives/zsh which will be a
link to /usr/local/bin/zsh which you built.

Normally, /etc/alternatives/zsh would be a link to /bin/zsh4 on wheezy
(zsh package 4.3.17-1), I presume /bin/zsh5 on testing or unstable.

Greg

Re: zsh 5.0.7

[Ray Andrews]

On 10/13/2014 12:02 PM, Greg Klanderman wrote:

Greg,

One day, when I know what all that is going to do!

For  now, it seems fine to just edit the '/etc/alternative/zsh*' links. 
So far it
hasn't hiccuped and should I need to, I can edit it back to 
'/usr/bin/zsh5' in case
I think I've found a bug or something.
> Hi Ray, on Debian, I build/install zsh as normal (not setting any
> prefix path options, let it install in /usr/local/bin/zsh) then do
> this:
>
> update-alternatives --install /bin/zsh zsh /usr/local/bin/zsh 100 \
>            --slave /usr/bin/zsh zsh-usrbin /usr/local/bin/zsh
>
> and it will have /bin/zsh and /usr/bin/zsh point to your locally built
> ones instead of the Debian provided packaged ones.
>
> i.e. /bin/zsh will be a link to /etc/alternatives/zsh which will be a
> link to /usr/local/bin/zsh which you built.
>
> Normally, /etc/alternatives/zsh would be a link to /bin/zsh4 on wheezy
> (zsh package 4.3.17-1), I presume /bin/zsh5 on testing or unstable.
>
> Greg
>

Re: zsh 5.0.7

[Greg Klanderman]

>>>>> On October 13, 2014 Ray Andrews <rayandrews@eastlink.ca> wrote:

> One day, when I know what all that is going to do!

> For now, it seems fine to just edit the '/etc/alternative/zsh*'
> links. So far it hasn't hiccuped and should I need to, I can edit it
> back to '/usr/bin/zsh5' in case I think I've found a bug or
> something.

Yeah I'm not usually one to just trust the magic, but all it's doing
is manipulating that link for you and storing your preference so that
it doesn't get reverted at some point when you upgrade..

Greg

Re: zsh 5.0.7

[Ray Andrews]

On 10/13/2014 03:58 PM, Greg Klanderman wrote:

> Yeah I'm not usually one to just trust the magic, but all it's doing 
> is manipulating that link for you and storing your preference so that 
> it doesn't get reverted at some point when you upgrade.. Greg 

I just wrote a little script to toggle back and forth between the two.  
What I'm thinking is that this way Debian upgrades can do whatever they 
want, and I can always have my latest testing build as well since they 
keep out of each other's way.  So long as all I have to do is change 
those links, I'm happy as a clam, I can run either one with ease.

Re: zsh 5.0.7

[Greg Klanderman]

glad you're happy, though it sounds like you've just reinvented
update-alternatives..

greg

Re: zsh 5.0.7

[Ray Andrews]

On 10/14/2014 01:12 PM, Greg Klanderman wrote:
> glad you're happy, though it sounds like you've just reinvented
> update-alternatives..
>
> greg
>
Yabut, at least this way *I* know how it works ;-)  As time goes on I'm 
sure I'll
be doing things more standard.

combining .histfiles

[Ray Andrews]

Bart,

.histfiles files merged fine, all good, except that somewhere along the 
line I managed to do this:

     . ~/.histfile

and it merrily started executing everything in my history. Nothing would 
stop it until I
jumped under my desk and pulled out the computer's plug.  Is this safe? 
It didn't occur to
me that the history file could be executed, should it be?  Anyway, 
thankfully the oldest commands
in .histfile were slow copyings that did no harm, so I'm undamaged, but 
I hafta wonder ....
And how does one stop this kind of thing once it gets going short of 
pulling out the plug?

Re: combining .histfiles

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

On Oct 14, 2014 10:19 AM, "Ray Andrews" <rayandrews@eastlink.ca> wrote:
>
> .histfiles files merged fine, all good, except that somewhere along the
line I managed to do this:
>
>     . ~/.histfile
>
> and it merrily started executing everything in my history.

Yes, history files have historically (ahem) been kept in a format that is
readable as shell command input.  I suspect this may date from early csh
implementations that reloaded the history by disabling command execution
and then running the file through the parser.

> Nothing would stop it until I
> jumped under my desk and pulled out the computer's plug.

Hmm, I don't know any reason why a regular interrupt (Ctrl+c) would not
stop "." execution, regardless of whether the script is a history file or
any other script, as long as the commands being executed are themselves
interruptible.

You mentioned a "slow copy" ... I've found that if an external command is
in disk wait state it may not respond to interrupts.  Sometimes a Ctrl+z
will suspend such a job even when Ctrl+c won't kill it.

Re: combining .histfiles

[Ray Andrews]

On 10/14/2014 03:04 PM, Bart Schaefer wrote:

Bart,
> and it merrily started executing everything in my history.
> Yes, history files have historically (ahem) been kept in a format that is
> readable as shell command input.  I suspect this may date from early csh
> implementations that reloaded the history by disabling command execution
> and then running the file through the parser.
I suppose there could be some good reason for it, but sheesh ...
> Hmm, I don't know any reason why a regular interrupt (Ctrl+c) would 
> not stop "." execution, regardless of whether the script is a history 
> file or any other script, as long as the commands being executed are 
> themselves interruptible. 
I could stop the command on each line  individually,  but not the 
.histfile *itself*.  Is there some way to
to break out of it?
> You mentioned a "slow copy" ... I've found that if an external command 
> is in disk wait state it may not respond to interrupts. Sometimes a 
> Ctrl+z will suspend such a job even when Ctrl+c won't kill it. 
I should have said 'large copy'.  A system backup actually, so it gave 
me time to dive for the power.  I
hate to think of the mess that might have been made, however.  If there 
was ever a file that should
be somehow protected from running, that's it.

Re: combining .histfiles

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

On Oct 14, 2014 3:24 PM, "Ray Andrews" <rayandrews@eastlink.ca> wrote:
>
> I could stop the command on each line  individually,  but not the
.histfile *itself*.  Is there some way to
> to break out of it?

As I said, Ctrl+c should do it.  I just now manufactured a file with a few
hundred "cp largefile /dev/null" commands, read it with "." and was able to
end it with Ctrl+c before it made it all the way through.

Of course if the history file contains a command to trap or otherwise
disable tty interrupts, you're stuck once that is reached.  Ctrl+z will
only suspend the current command, not the whole script.

Incidentally the reason the file format is that way is so that it can be
shared with other (non-zsh) shells if desired.  That's probably not very
often desired any more.

It occurs to me that it might be feasible to ensure that the first line of
the history file is always "return 1".  There'd be some potential user
confusion to dispel ("why is my history file 101 lines long when I have
SAVEHIST set to 100?").  On the other hand, you are the first person I've
ever heard of make this particular mistake.  :-) :-/

Re: combining .histfiles

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On 10/14/2014 04:55 PM, Bart Schaefer wrote:
>
> On Oct 14, 2014 3:24 PM, "Ray Andrews" <rayandrews@eastlink.ca 
> <mailto:rayandrews@eastlink.ca>> wrote:
> >
> > I could stop the command on each line  individually,  but not the 
> .histfile *itself*.  Is there some way to
> > to break out of it?
>
> As I said, Ctrl+c should do it.  I just now manufactured a file with a 
> few hundred "cp largefile /dev/null" commands, read it with "." and 
> was able to end it with Ctrl+c before it made it all the way through.
>
Hmmm, it didn't work here, I hit Ctrl+c a dozen times, it didn't break 
out. I'll try to figure out why.
> On the other hand, you are the first person I've ever heard of make 
> this particular mistake.  :-) :-/
Well then never mind.  You can be sure I'll never do it again, that is 
for sure! What with the file format, all those leading numbers, it 
didn't look executable so the worst thing is that it was such a huge 
shock.  Never more. But it does make me question what *isn't* executable.

Re: combining .histfiles

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]

For the benefit of anyone lurking on this thread who is confused why those
funky looking lines are syntactically legal (which probably doesn't include
Ray or Bart)... If you look carefully you'll see the format of the histfile
is

  colon timestamp semicolon command

The leading colon is the null command which does nothing with its args and
returns a zero (success) exit status. The semicolon separates it from the
"real" command. So entering something like

  : 1234:5 ; echo hello

is the same as just typing

  echo hello

The colon command is mostly useful when you want the side effects from
parsing the rest of the args without running a command.

On Tue, Oct 14, 2014 at 6:02 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> On 10/14/2014 04:55 PM, Bart Schaefer wrote:
>
>>
>> On Oct 14, 2014 3:24 PM, "Ray Andrews" <rayandrews@eastlink.ca <mailto:
>> rayandrews@eastlink.ca>> wrote:
>> >
>> > I could stop the command on each line  individually,  but not the
>> .histfile *itself*.  Is there some way to
>> > to break out of it?
>>
>> As I said, Ctrl+c should do it.  I just now manufactured a file with a
>> few hundred "cp largefile /dev/null" commands, read it with "." and was
>> able to end it with Ctrl+c before it made it all the way through.
>>
>>  Hmmm, it didn't work here, I hit Ctrl+c a dozen times, it didn't break
> out. I'll try to figure out why.
>
>> On the other hand, you are the first person I've ever heard of make this
>> particular mistake.  :-) :-/
>>
> Well then never mind.  You can be sure I'll never do it again, that is for
> sure! What with the file format, all those leading numbers, it didn't look
> executable so the worst thing is that it was such a huge shock.  Never
> more. But it does make me question what *isn't* executable.
>
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: combining .histfiles

[Ray Andrews]

On 10/14/2014 06:09 PM, Kurtis Rader wrote:
>    : 1234:5 ; echo hello
>
> is the same as just typing
>
>    echo hello
>
> The colon command is mostly useful when you want the side effects from
> parsing the rest of the args without running a command.
>
Ah! Now that you explain it, it's as clear as Zeiss glass. Tx.  This 
means that I can just grab
a block of lines from .histfile and they are 'already' a script--no need 
to massage out those
numbers.  Most cool.  At the end of our suffering is enlightenment.

c++ comments

[Ray Andrews]

Enlightened Ones:

How can I legalize c++ comments? Or would that be a deep blasphemy? As 
it is, well nuts, you'd think it would give me a msg: "No c++ comments 
permitted, sinner" but instead it gives me msg. about static 
declarations and such ;-)

Re: c++ comments

[Bart Schaefer]

On Oct 22,  7:58pm, Ray Andrews wrote:
}
} How can I legalize c++ comments? Or would that be a deep blasphemy?

Zsh historically has been built with compilers that do not support c++
comment syntax.  I'm not rabidly opposed to it, but tend to think we
should continue to avoid it in the zsh sources.

The foregoing assumes I correctly understand what "legalize" means to
you, and that the zsh sources are in fact what you're talking about.

} As it is, well nuts, you'd think it would give me a msg: "No c++
} comments permitted, sinner" but instead it gives me msg. about static
} declarations and such ;-)

You mostly lost me here.  If the compiler doesn't handle c++ syntax,
it's not going to be able to tell that a c++ comment is what confused
it; it's just going to cough up a syntax error and possibly some other
errors if it tries to keep on parsing.

Also, zsh's build process depends on being able to recognize some
comment markers and use that information to extract declarations into
automatically-generated header files, so even if the compiler did
understand c++ comments you could get into trouble if you changed the
wrong existing comment into that syntax.  That's probably not what you
are doing anyway.

As a final note, you should direct questions about the zsh internals
to the zsh-workers list instead of to zsh-users.  The latter is for
questions about shell interaction, scripts, etc., though some internal
stuff does cross the boundary in bug report threads.