* &&|| @ 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-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 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-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
* !!:$ @ 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: !!:$ 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
* 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 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 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 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-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-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
* ?????? @ 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
* 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
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).