lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Odd behavior with zsh


From: Greg Chicares
Subject: Re: [lmi] Odd behavior with zsh
Date: Wed, 16 Dec 2015 20:06:46 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0

On 2015-12-16 19:04, Vadim Zeitlin wrote:
> On Wed, 16 Dec 2015 17:02:57 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> for z in * ; do grep --quiet --files-with-matches '$Id:' $z && touch 
> "--date=$(<$z sed -e'/$Id:/!d' |sed -e's/^.* [0-9][0-9]* \([0-9]\{4\}[-0-9: 
> ]*\).*$/\1/')" $z && date -u +'%Y%m%dT%H%MZ' -r $z; done;
> GC> 
> GC> which has always worked,
> 
>  Off topic, but I'd replace "*" above with "*(.)" to avoid grepping
> directories, which results in errors.

Good point. Wouldn't '--directories=skip' be more robust though?

> GC> However...at first I didn't realize that this file contains no '$Id:' 
> date,
> GC> so I pressed up-arrow and tried modifying and re-executing the command:
                                      ^^^^^^^^^
[...]
> GC> and zsh spat back an old command. My latest command has no 'for' or 
> 'grep',
> GC> but what zsh says mentions both, for instance.
> 
>  I am not sure if I understand correctly what happens here but for me, if I
> enter the command copy and pasted from above, press "Enter" and then "Up",
> I get exactly the same command back:
[...]
> Of course, the _output_ of this command still contains "for" and "grep"
> because this is what comes from gwc/develop1.txt file. But the command
> itself doesn't change for me, does it really do this for you?

It doesn't change all by itself. I edit it manually, mostly using
backspace and delete to try to get to the shortest command that
reproduces the behavior that I don't understand.

In the past, this has always worked. If the original command
  svn foo --bar=baz
failed, I might hit up-arrow, End, and backspace until it's down to
  svn foo
and then I hit Enter to see whether that simpler command works.
In that case, I expect the session to look like this:

[0]$svn foo --bar=baz
svn: invalid option: --bar=baz
Type 'svn help' for usage.
[1]$svn foo
Unknown subcommand: 'foo'
Type 'svn help' for usage.
[1]$

and that is exactly what I see for the 'svn foo --bar=baz' example.
But for the other command, it's as though my session looked like
this after editing the command and pressing Enter:

[0]$svn foo --bar=baz
svn: invalid option: --bar=baz
Type 'svn help' for usage.
[1]$svn foo
svn foo --bar=baz
svn: invalid option: --bar=baz
Type 'svn help' for usage.
[1]$




reply via email to

[Prev in Thread] Current Thread [Next in Thread]