zsh-users
 help / color / mirror / code / Atom feed
* &&||
@ 2018-02-19 21:12 Ray Andrews
  2018-02-19 21:57 ` &&|| Peter Stephenson
  0 siblings, 1 reply; 19+ messages in thread
From: Ray Andrews @ 2018-02-19 21:12 UTC (permalink / raw)
  To: Zsh Users

function test ()
{
     _aaray=`ls`
     [ true ] && { print -l "${ _aaray[@]}" | GREP_COLOR='01;33' egrep 
--color=always "$1"\

| GREP_COLOR='01;31' egrep --color=always "$2" }\

|| echo bust!
}

    $ touch present

    $ test present pres
    present                            << two colors.

    $ test present pppres
    bust!

    $ test pppresent p
    bust!


When I first did this, I was puzzled by the output, then I wisely 
realized that the  '||'  was in fact responding to the return value of 
the failed egrep.  At first I did this without the braces and was 
content with what happened but I'd expect the braces to force the '||' 
to respond to the leading test (which of course never varies here being 
true all the time) and thus never give me a 'bust!' regardless of the 
egrep return value.  I solved the issue by using an 'if/else' 
construction but still I'm curious about the above.  Is my expectation 
mistaken?  Within an '&& ||' construction how would I write that to do 
as I was expecting -- respond to the truth value of the initial test?  
When I use braces in complex '&& ||' situations they always seem to 
behave as expected.  I do have the niggling feeling my expectation above 
is wrong, but I can't quite say why.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: &&||
  2018-02-19 21:12 &&|| Ray Andrews
@ 2018-02-19 21:57 ` Peter Stephenson
  2018-02-19 22:47   ` &&|| Ray Andrews
  0 siblings, 1 reply; 19+ messages in thread
From: Peter Stephenson @ 2018-02-19 21:57 UTC (permalink / raw)
  To: Zsh Users

On Mon, 19 Feb 2018 13:12:20 -0800
Ray Andrews <rayandrews@eastlink.ca> wrote:

> function test ()
> {
>      _aaray=`ls`

You never need to use output from ls in a shell unless you need long
output like ls -l (and there are ways round that, too).  This should be

_aarray=(*)

and you get the full power of globbing if you wanted to vary the
contents in some way.  Strictly, I suppose it should be

_aarray=(*(N))

to give you an empty array rather than an error if there are no files
that don't begin with a dot.

>      [ true ] && { print -l "${ _aaray[@]}" | GREP_COLOR='01;33' egrep 

Do you mean just "true"?  Not sure what putting this in square brackets
is supposed to achieve.  It does work, but purely by virtue of the fact
that the string "true" has non-zero length --- as does the string
"false", which is one of several reasons I'd avoid this.

> --color=always "$1"\
>
> | GREP_COLOR='01;31' egrep --color=always "$2" }\
> 
> || echo bust!

If you read the documentation about && and || (OK, OK, I'm joking, I'm
joking) you'll find the statement:

  Both operators have equal precedence and are left associative. 

That's written for geeks, but what it means is the shell simply looks
through from left to right, taking the &&s and ||s as they come:

- If it finds "&&" at any point, it executes the following chunk if the
previous returned status true.  Otherwise, it skips it and looks for any
further "&&" or "||".

- If it finds "||" at any point, it executes the following chunk if the
previous returned status false.  Otherwise, it skips it and looks for
any further "&&" or "||".

I've skipped over the fact that actually it may not have executed
the chunk before the "&&" or "||" it's looking at.  So where I
said "the previous status returned" you should really think of
"the last status of anything it did execute was...".  So

false && true || true

- runs false to get status (surprise!) false.

- looks at the "&&" and decides "nah, skip the next bit".

- looks at the "||" and still has status false, so executes the true.

That should give you enough of a hint to follow any combination.

Note this is not how && and || work in C, or even in zsh's own
arithmetic context which is much more like C than the standard shell
syntax is.

You can affect the precedence with braces, but they need to surround the
"&&" or "||" expression you want to protect.  In your case you've simply
surrounded a pipeline which would be run in one go anyway:

% echo one && echo one | sed -e s/o/a/
one
ane

is just the same as

% echo one && { echo one | sed -e s/o/a/ }
one
ane

and sticking more of the poor suffering &&s and ||s after doesn't change
it, either.

> }

pws


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: &&||
  2018-02-19 21:57 ` &&|| Peter Stephenson
@ 2018-02-19 22:47   ` Ray Andrews
  2018-02-20  9:26     ` &&|| Peter Stephenson
  0 siblings, 1 reply; 19+ messages in thread
From: Ray Andrews @ 2018-02-19 22:47 UTC (permalink / raw)
  To: zsh-users

On 19/02/18 01:57 PM, Peter Stephenson wrote:
> You never need to use output from ls in a shell
Yeah, I was just trying to make a fast list of something to filter. 
Mind, I do tend to forget about zsh's internal power when it comes to 
that sort of thing so the reminder is welcome.

> Do you mean just "true"? Not sure what putting this in square brackets 

Right, 'true' and 'false' live without any syntactic wrapping.  I forgot.

> is supposed to achieve.  It does work, but purely by virtue of the fact
>
> You can affect the precedence with braces, but they need to surround the
> "&&" or "||" expression you want to protect.  In your case you've simply
> surrounded a pipeline which would be run in one go anyway:
That's my question, could my code be made to work more or less as it 
is?  I was expecting the braces to work.  Otherwise I fairly well 
understand the basic rules esp. the left>right thing, it really does 
make life a bit simpler.  Mind, I suppose that since return values are 
always suspect perhaps an if/else construction really is just better.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: &&||
  2018-02-20  9:26     ` &&|| Peter Stephenson
@ 2018-02-20  7:54       ` Ray Andrews
  2018-02-20 17:07         ` &&|| Peter Stephenson
  0 siblings, 1 reply; 19+ messages in thread
From: Ray Andrews @ 2018-02-20  7:54 UTC (permalink / raw)
  To: zsh-users

On 20/02/18 01:26 AM, Peter Stephenson wrote:
> I think you were trying to make the status depend only on what was
> before the first "&&".  You can certainly do
But isn't that exactly what I did do?  Appending to you code below:

> first-statement && {
>     any-old-stuff
> } || {something-else-entirely}
Yet the return value of any-old-stuff (egrep in practice) was what 
actually controlled something-else-entirely.  I'm not expecting the 
pipes within any braced structure to make any difference.  Is that 
what's happening?  Is so, how/why?  Do not the braces pointedly force 
the entire structure to be subordinate to the first '&&'?  It seems to 
me that the left>right association in my original code is sorta 
'brutally' adhered to in such a way that the natural meaning of the 
braces is violated such that any-old-stuff has control of branching when 
the natural logic is that first-statement has it.  Yes? No?


if first-statement; then
     { any-old-stuff}
else
     {something-else-entirely}
fi

That works fine egrep and/or pipes notwithstanding, yet I'm expecting 
both to work the same.  You seem to suggest they should as well.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: &&||
  2018-02-19 22:47   ` &&|| Ray Andrews
@ 2018-02-20  9:26     ` Peter Stephenson
  2018-02-20  7:54       ` &&|| Ray Andrews
  0 siblings, 1 reply; 19+ messages in thread
From: Peter Stephenson @ 2018-02-20  9:26 UTC (permalink / raw)
  To: zsh-users

On Mon, 19 Feb 2018 14:47:12 -0800
Ray Andrews <rayandrews@eastlink.ca> wrote:
> > You can affect the precedence with braces, but they need to surround the
> > "&&" or "||" expression you want to protect.  In your case you've simply
> > surrounded a pipeline which would be run in one go anyway:
> That's my question, could my code be made to work more or less as it 
> is?

I think you were trying to make the status depend only on what was
before the first "&&".  You can certainly do

first-statement && {
   any-old-stuff
}

and it does have the effect of "if", though there's no obvious reason to
prefer this form (some old shell code is indeed written this way).  The
key points are

- the open brace is the first thing after the &&
- the close brace is after the last thing you want controlled by the
status of first-statement.

The real point, perhaps, is to be able to separate out that
any-old-stuff as something contained within the block, however
complicated it is by itself, so you may just have been getting
distracted by pipelines and ||s etc.

pws


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: &&||
  2018-02-20  7:54       ` &&|| Ray Andrews
@ 2018-02-20 17:07         ` Peter Stephenson
  2018-02-20 19:24           ` &&|| Ray Andrews
  0 siblings, 1 reply; 19+ messages in thread
From: Peter Stephenson @ 2018-02-20 17:07 UTC (permalink / raw)
  To: zsh-users

On Mon, 19 Feb 2018 23:54:38 -0800
Ray Andrews <rayandrews@eastlink.ca> wrote:

> On 20/02/18 01:26 AM, Peter Stephenson wrote:
> > I think you were trying to make the status depend only on what was
> > before the first "&&".  You can certainly do
> But isn't that exactly what I did do?

No.

> Appending to you code below:
> 
> > first-statement && {
> >     any-old-stuff
> > } || {something-else-entirely}

The status of first-statement only controls what's *inside* the { }.
That's what I showed.  You've now stuck something after it.  That's got
completely different rules, interacting both with the && outside the braces
as well as the last status from within the braces.

You've now extended your demand so that it works with an else clause as
well.  That can't be done simply by combining &&s and ||s on the same
level (without other fix-ups) because they don't have the same rules.

You could do this, I suppose.

first-statement && {
    any-old-stuff
    true
} || {something-else-entirely}

That works because

- if you don't execute first-statmement, you go direct to what's
following the "||";

- if you do execute it you then get to the true, which is the last
status for the brace, which causes what's following the "||" to be
ignored.

But you'd probably be (as my father would have said) stotting bonkers.
Though it is a pretty good illustration of the difference between the
two cases.

pws


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: &&||
  2018-02-20 17:07         ` &&|| Peter Stephenson
@ 2018-02-20 19:24           ` Ray Andrews
  2018-02-20 20:28             ` &&|| Bart Schaefer
  0 siblings, 1 reply; 19+ messages in thread
From: Ray Andrews @ 2018-02-20 19:24 UTC (permalink / raw)
  To: zsh-users

On 20/02/18 09:07 AM, Peter Stephenson wrote:
> You've now extended your demand so that it works with an else clause as 

Not 'extended' that is the entire point of my question. I'm expecting 
the '||' to be identical to a logical 'else', there is no other issue.

Demand? I seek clarification, mind, if it were agreed that my sense of 
the logic were correct I'd be happy to see it change, but issues of 
logic and code flow are rigorous and not subject to opinion.
> You could do this, I suppose.
>
> first-statement && {
>      any-old-stuff
>      true				<< right, I see how that protects.
> } || {something-else-entirely}

Ok, I'm at least on guard for that sort of thing from now on.  I've more and more been using &&|| constructions in place of if/else simply because the former is more compact, but I'll be more vigilant from now on.  Braces are ignored as far as truth tests on the left of any && or ||.  I can't say I like it tho, not that that matters, a thing like this is entirely at your discretion.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: &&||
  2018-02-20 19:24           ` &&|| Ray Andrews
@ 2018-02-20 20:28             ` Bart Schaefer
  2018-02-20 21:45               ` &&|| Ray Andrews
  0 siblings, 1 reply; 19+ messages in thread
From: Bart Schaefer @ 2018-02-20 20:28 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On Tue, Feb 20, 2018 at 11:24 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> On 20/02/18 09:07 AM, Peter Stephenson wrote:
>>
>> You've now extended your demand so that it works with an else clause as
>
> Not 'extended' that is the entire point of my question. I'm expecting the
> '||' to be identical to a logical 'else', there is no other issue.

But "||" is not "else" and "&&" is not "if" -- rather they are "and" /
"or" (which is why they use the symbols they do).

first-statement AND second-statement OR third-statement

The implicit grouping is left-to-right, so that's the same as

{ first-statement AND second-statement } OR third-statement

Thus the first pair succeeds only when both succeed, and
third-statement occurs when the first pair fails.  To express this
with if/else you would write

if first-statement;
then
 if second-statement;
 then
  true;
 else
  false;
 fi;
else
 false;
fi;
if [[ $? -eq 0 ]];
then
 if third-statement;
 then
  true;
 else
  false;
 fi;
else
 false;
fi

> Demand? I seek clarification

I believe PWS meant "demand" in the sense of what your statement asks
of the shell, not what you're asking him to explain.

> Braces are
> ignored as far as truth tests on the left of any && or ||.

No, that's entirely wrong.  Braces always return the final status of
the enclosed list of statements.  && and || always use the final
status of the entire chain of any && or || to their left.  The two are
related only when the braces surround another chain of && or || but
only in so far as that affects the final status of the braces.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: &&||
  2018-02-20 20:28             ` &&|| Bart Schaefer
@ 2018-02-20 21:45               ` Ray Andrews
  0 siblings, 0 replies; 19+ messages in thread
From: Ray Andrews @ 2018-02-20 21:45 UTC (permalink / raw)
  To: zsh-users

On 20/02/18 12:28 PM, Bart Schaefer wrote:


That was a master class in logic.  Thank you Sensei.

>> ignored as far as truth tests on the left of any && or ||.
> No, that's entirely wrong.  Braces always return the final status of
> the enclosed list of statements.  && and || always use the final
> status of the entire chain of any && or || to their left.  The two are
> related only when the braces surround another chain of && or || but
> only in so far as that affects the final status of the braces.
Yes, I get it.  I was asking/expecting the braces to throw decision 
leftward to the preceding '&&' whereas they properly create a { combined 
truth test } to be thrown rightward to the following '||'  exactly as 
they should!

So the fact that one can often set up an &&/|| structure that looks very 
much like an if/else structure, and the fact that they will very often 
behave the same way, does not make them logically identical!!  I feel 
purified of a sin ;-)

Thanks Peter too, I know I flog these things to death.



>


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: !!:$
  2004-11-17 19:25   ` !!:$ Danek Duvall
@ 2004-11-18  1:10     ` Bart Schaefer
  0 siblings, 0 replies; 19+ messages in thread
From: Bart Schaefer @ 2004-11-18  1:10 UTC (permalink / raw)
  To: Danek Duvall; +Cc: zsh-users

On Wed, 17 Nov 2004, Danek Duvall wrote:

> fc -e isn't described in zshbuiltins(1), though it's mentioned in fc's
> synopsis.  Bug?

It is described, it's just not as clear as it could be.

The synopsis says:

  fc [ -e ENAME ] [ -nlrdDfEim ] [ OLD=NEW ... ] [ FIRST [ LAST ] ]

and then the text says (in part):

     If the -l flag is given [...]  Otherwise the editor
     program ENAME is invoked on a file containing these history
     events.  If ENAME is not given, the value of the parameter FCEDIT
     is used.  If ENAME is `-', no editor is invoked.  When editing is
     complete, the edited command is executed.

So although it doesn't mention "-e", it describes the argument of -e, and 
you can't give the argument without giving the option, so ...


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: !!:$
  2004-11-17  0:03 ` !!:$ Bart Schaefer
@ 2004-11-17 19:25   ` Danek Duvall
  2004-11-18  1:10     ` !!:$ Bart Schaefer
  0 siblings, 1 reply; 19+ messages in thread
From: Danek Duvall @ 2004-11-17 19:25 UTC (permalink / raw)
  To: zsh-users

On Tue, Nov 16, 2004 at 04:03:31PM -0800, Bart Schaefer wrote:

>   alias ch='fc -e fcch'

fc -e isn't described in zshbuiltins(1), though it's mentioned in fc's
synopsis.  Bug?

Danek


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: !!:$
  2004-11-16 13:45 !!:$ keef
  2004-11-16 14:22 ` !!:$ Peter Stephenson
@ 2004-11-17  0:03 ` Bart Schaefer
  2004-11-17 19:25   ` !!:$ Danek Duvall
  1 sibling, 1 reply; 19+ messages in thread
From: Bart Schaefer @ 2004-11-17  0:03 UTC (permalink / raw)
  To: zsh-users

On Tue, 16 Nov 2004, keef wrote:

> something to the effect of:
> alias ch="chmod 755 !!:$"

This is what the "fc" command is for, by the way.

  fcch() {
    emulate -L zsh
    # We're passed a file name, so:
    # - read it
    # - split it into shell words
    # - and grab the last one
    local w=${${(z)"$(<$1)"}[-1]}
    # Write back the edited command
    print "chmod 755 ${(qq)w}" >| $1
  }
  alias ch='fc -e fcch'


With that, you can even do e.g.

  ch -3

to chmod the last argument from the third command back instead of the 
immediately preceding command.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: !!:$
  2004-11-16 15:37   ` !!:$ Bart Schaefer
@ 2004-11-16 16:08     ` Peter Stephenson
  0 siblings, 0 replies; 19+ messages in thread
From: Peter Stephenson @ 2004-11-16 16:08 UTC (permalink / raw)
  To: zsh-users

Stephane Chazelas wrote:
> Wouldn't it be the same as ${(%):-%!}?

Yes, except much more obvious.

Bart wrote:
> Umm.
> 
> HISTNO (integer)
>      The current history number.  Setting this has the same effect as
>      moving up or down in the history to the corresponding history line.
>      An attempt to set it is ignored if the line is not stored in the
>      history.
> 
> Admittedly this is available only in widgets, but it seems odd to have two
> variables for the same thing.

You didn't read down the patch far enough.

+history.  Note this is not the same as the parameter tt(HISTCMD),
+which always give the number of the history line being added to the main
+shell's history.  tt(HISTNO) refers to the line being retrieved within
+zle.

>> Then you can always get the full previous line as
>> $history[$((HISTCMD-1))].
>
> Unfortunately that doesn't always work.  If you setopt HIST_IGNORE_DUPS,
> $history[$((HISTNO-1))] may be empty.

That's a nuisance.  Maybe we need an ordinary array which always gives
the last items in the history, too.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: !!:$
  2004-11-16 14:22 ` !!:$ Peter Stephenson
  2004-11-16 14:31   ` !!:$ Stephane Chazelas
@ 2004-11-16 15:37   ` Bart Schaefer
  2004-11-16 16:08     ` !!:$ Peter Stephenson
  1 sibling, 1 reply; 19+ messages in thread
From: Bart Schaefer @ 2004-11-16 15:37 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: zsh-users

On Tue, 16 Nov 2004, Peter Stephenson wrote:

> [...]  $history is an associative array and you need
> to know the event number, which currently isn't available as a
> parameter: you can get it from a prompt, but not directly.  This strikes
> me as a curious omission.  How about adding it using the same name as
> bash?

Umm.

HISTNO (integer)
     The current history number.  Setting this has the same effect as
     moving up or down in the history to the corresponding history line.
     An attempt to set it is ignored if the line is not stored in the
     history.

Admittedly this is available only in widgets, but it seems odd to have two
variables for the same thing.

> Then you can always get the full previous line as
> $history[$((HISTCMD-1))].

Unfortunately that doesn't always work.  If you setopt HIST_IGNORE_DUPS,
$history[$((HISTNO-1))] may be empty.

The only thing that always works is $history[${${(Onk)history}[1]}] or
some similar convolution that gets keys that are known to be in the hash.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: !!:$
  2004-11-16 14:22 ` !!:$ Peter Stephenson
@ 2004-11-16 14:31   ` Stephane Chazelas
  2004-11-16 15:37   ` !!:$ Bart Schaefer
  1 sibling, 0 replies; 19+ messages in thread
From: Stephane Chazelas @ 2004-11-16 14:31 UTC (permalink / raw)
  To: zsh-users

On Tue, Nov 16, 2004 at 02:22:28PM +0000, Peter Stephenson wrote:
[...]
> me as a curious omission.  How about adding it using the same name as
> bash?  Then you can always get the full previous line as
> $history[$((HISTCMD-1))].  Hence you can do lots of tricks.  The
> equivalent of the above would be:
> 
[...]
> +vindex(HISTCMD)
> +item(tt(HISTCMD))(
> +The current history line number in an interactive shell, in other
> +words the line number for the command that caused tt($HISTCMD)
> +to be read.
> +)
[...]

Wouldn't it be the same as ${(%):-%!}?

-- 
Stéphane


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: !!:$
  2004-11-16 13:45 !!:$ keef
@ 2004-11-16 14:22 ` Peter Stephenson
  2004-11-16 14:31   ` !!:$ Stephane Chazelas
  2004-11-16 15:37   ` !!:$ Bart Schaefer
  2004-11-17  0:03 ` !!:$ Bart Schaefer
  1 sibling, 2 replies; 19+ messages in thread
From: Peter Stephenson @ 2004-11-16 14:22 UTC (permalink / raw)
  To: zsh-users

keef wrote:
> yarr mateys!

Er, yeah.

> consider the following:
> 
> % touch somefile
> % chmod 755 !!:$
> 
>  -this essentially will chmod 755 the last arg in the previous history cmd
> 
> now then, id like to incorporate this into my .zshrc
> 
> something to the effect of:
> alias ch="chmod 755 !!:$"

Try:

  alias ch='chmod 755 $_'

It works in this case, but you can't get the full effect of history
expansion in an alias since they are expanded too late.

The zsh/parameter module does have $history and $historywords to help
access the history, but unfortunately the interface isn't very easy to
use in a case like this.  $history is an associative array and you need
to know the event number, which currently isn't available as a
parameter: you can get it from a prompt, but not directly.  This strikes
me as a curious omission.  How about adding it using the same name as
bash?  Then you can always get the full previous line as
$history[$((HISTCMD-1))].  Hence you can do lots of tricks.  The
equivalent of the above would be:

ch() {
   # Don't want ksh_arrays, ...
   emulate -L zsh

   # Make sure the parameter module is loaded
   zmodload -i zsh/parameter

   local prev
   # Split the previous line using normal shell word splitting.
   prev=(${(z)history[$((HISTCMD-1))]})
   # Retrieve the final element of the line.
   chmod 755 $prev[-1]
}

Index: Doc/Zsh/params.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/params.yo,v
retrieving revision 1.23
diff -u -r1.23 params.yo
--- Doc/Zsh/params.yo	8 Oct 2004 14:37:24 -0000	1.23
+++ Doc/Zsh/params.yo	16 Nov 2004 14:17:28 -0000
@@ -535,6 +535,12 @@
 command under a different
 group ID by `tt(LPAR()GID=)var(gid)tt(; command+RPAR())'
 )
+vindex(HISTCMD)
+item(tt(HISTCMD))(
+The current history line number in an interactive shell, in other
+words the line number for the command that caused tt($HISTCMD)
+to be read.
+)
 vindex(HOST)
 item(tt(HOST))(
 The current hostname.
Index: Doc/Zsh/zle.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/zle.yo,v
retrieving revision 1.44
diff -u -r1.44 zle.yo
--- Doc/Zsh/zle.yo	22 Sep 2004 04:37:02 -0000	1.44
+++ Doc/Zsh/zle.yo	16 Nov 2004 14:17:29 -0000
@@ -645,7 +645,10 @@
 The current history number.  Setting this has the same effect as
 moving up or down in the history to the corresponding history line.
 An attempt to set it is ignored if the line is not stored in the
-history.
+history.  Note this is not the same as the parameter tt(HISTCMD),
+which always give the number of the history line being added to the main
+shell's history.  tt(HISTNO) refers to the line being retrieved within
+zle.
 )
 vindex(KEYMAP)
 item(tt(KEYMAP) (scalar))(
Index: Src/params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/params.c,v
retrieving revision 1.92
diff -u -r1.92 params.c
--- Src/params.c	1 Oct 2004 19:48:57 -0000	1.92
+++ Src/params.c	16 Nov 2004 14:17:30 -0000
@@ -184,6 +184,7 @@
 IPDEF4("!", &lastpid),
 IPDEF4("$", &mypid),
 IPDEF4("?", &lastval),
+IPDEF4("HISTCMD", &curhist),
 IPDEF4("LINENO", &lineno),
 IPDEF4("PPID", &ppid),
 

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************


^ permalink raw reply	[flat|nested] 19+ messages in thread

* !!:$
@ 2004-11-16 13:45 keef
  2004-11-16 14:22 ` !!:$ Peter Stephenson
  2004-11-17  0:03 ` !!:$ Bart Schaefer
  0 siblings, 2 replies; 19+ messages in thread
From: keef @ 2004-11-16 13:45 UTC (permalink / raw)
  To: zsh-users

yarr mateys!

consider the following:

% touch somefile
% chmod 755 !!:$

 -this essentially will chmod 755 the last arg in the previous history cmd

now then, id like to incorporate this into my .zshrc

something to the effect of:
alias ch="chmod 755 !!:$"

but this produces the error:
chmod: cannot access `!!:$': No such file or directory

apparently its looking for a literal filname of "!!:$"


can anyone out there recommend a way to go about doing this ?


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: ??????
  2003-07-02 15:06 ?????? JEFF BICKLEY
@ 2003-07-02 19:56 ` Thorsten Haude
  0 siblings, 0 replies; 19+ messages in thread
From: Thorsten Haude @ 2003-07-02 19:56 UTC (permalink / raw)
  To: zsh-users

Hi,

* JEFF BICKLEY <BICKLJ03@odjfs.state.oh.us> [2003-07-02 17:06]:
>** Low Priority **
>
>What is the zsh-users mailing list used for?

Propagating viruses mainly.


Thorsten
-- 
Nichts ist schwerer und erfordert mehr Charakter, als sich in offenem
Gegensatz zu seiner Zeit zu befinden und zu sagen: Nein!
    - Kurt Tucholsky


^ permalink raw reply	[flat|nested] 19+ messages in thread

* ??????
@ 2003-07-02 15:06 JEFF BICKLEY
  2003-07-02 19:56 ` ?????? Thorsten Haude
  0 siblings, 1 reply; 19+ messages in thread
From: JEFF BICKLEY @ 2003-07-02 15:06 UTC (permalink / raw)
  To: zsh-users

** Low Priority **

What is the zsh-users mailing list used for?


^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2018-02-20 21:45 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-19 21:12 &&|| Ray Andrews
2018-02-19 21:57 ` &&|| Peter Stephenson
2018-02-19 22:47   ` &&|| Ray Andrews
2018-02-20  9:26     ` &&|| Peter Stephenson
2018-02-20  7:54       ` &&|| Ray Andrews
2018-02-20 17:07         ` &&|| Peter Stephenson
2018-02-20 19:24           ` &&|| Ray Andrews
2018-02-20 20:28             ` &&|| Bart Schaefer
2018-02-20 21:45               ` &&|| Ray Andrews
  -- strict thread matches above, loose matches on Subject: below --
2004-11-16 13:45 !!:$ keef
2004-11-16 14:22 ` !!:$ Peter Stephenson
2004-11-16 14:31   ` !!:$ Stephane Chazelas
2004-11-16 15:37   ` !!:$ Bart Schaefer
2004-11-16 16:08     ` !!:$ Peter Stephenson
2004-11-17  0:03 ` !!:$ Bart Schaefer
2004-11-17 19:25   ` !!:$ Danek Duvall
2004-11-18  1:10     ` !!:$ Bart Schaefer
2003-07-02 15:06 ?????? JEFF BICKLEY
2003-07-02 19:56 ` ?????? Thorsten Haude

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).