Re: Return from function depending on number of parameters
On 03/07/2020 10:39 pm, Lawrence Velázquez wrote: On Jul 3, 2020, at 2:00 PM, Chris Elvidge wrote: However 'N=0; echo $((!$N))' gives an error at the bash prompt. 'echo $[!$N]' echo's 1 as expected. My question - is $[...] actually obsolete? It might tell you something that $[...] is not even mentioned in the man page for bash 3.2.57, which is decidedly not the current version. If so, what should I use at the bash prompt to get the same effect? I expect that the error you encountered was caused by !$ expanding to the last word of the previous command and making the contents of $((...)) an invalid arithmetic expression. This didn't affect your scripts because history expansion is not enabled in non-interactive shells by default. Try inserting a space. $ N=0; printf %s\\n "$((! $N))" 1 You can even drop the $. $ N=0; printf %s\\n "$((! N))" 1 vq Thanks for the info. It also explains why I couldn't find a reference to $[...] except in the reference I quoted. -- Chris Elvidge 5 Ebor Park, Appleton Roebuck, York. YO23 7DZ. Tel (Mob): +447443472958 mailto:celvi...@outlook.com Calle Padre Raimundo Codesal 1, Vélez-Málaga, 29700, España
Re: Return from function depending on number of parameters
On 03/07/2020 11:16 pm, Eli Schwartz wrote: On 7/3/20 2:00 PM, Chris Elvidge wrote: I've used 'return $((!$#))' and 'return $[!$#]' to return an error if no parameters given to function. Tested in a bash script 'exit $((!$#)) / $[!$#]' - both work. 'echo $((!$#)) / $[!$#]' - both echo 1 when no params, 0 when any number of params. I'm told ( https://wiki.bash-hackers.org/scripting/obsolete ) that $[...] is obsolete and that $((...)) should be used instead. OK so far. However 'N=0; echo $((!$N))' gives an error at the bash prompt. 'echo $[!$N]' echo's 1 as expected. "gives an error" is a useless bug report. It works for me. $ N=0; echo $((!$N)) 1 My initial reaction to reading this thread is head scratching! As the other reply mentioned, there's actually a good explanation for why we get different results -- I disabled an annoying feature. $ set -o histexpand Now here's a useful bug report. "When I run this, I get the following incorrect results or error message": $ N=0; echo $((!$N)) N=0; echo $((histexpandN)) 0 $ N=0; echo $((!$N)) N=0; echo $(()N)) -bash: syntax error near unexpected token `)' $ N=0 $ echo $((!$N)) echo $((N=0N)) -bash: N=0N: value too great for base (error token is "0N") ... From there, people can give useful advice for solving the problem. (My preferred advice is "disable histexpand".) Thanks for the pointers to a better bug report. And thanks for the info on histexpand. I obviously should read the manual more carefully - I'd never come across it - as it's set by default, not in any profile or bashrc file. Did you mean set +o histexpand to disable the feature? -- Chris Elvidge
Re: Return from function depending on number of parameters
On 04/07/2020 04.39, Lawrence Velázquez wrote: > It might tell you something that $[...] is not even mentioned in > the man page for bash 3.2.57, which is decidedly not the current > version. About that, is it for sure that $[] is going to be obsoleted/removed in the future? I happened to use it recently, and thought it was more readable than $(()) and caused less visual clutter. Any reason $(()) was preferred? Peter
Re: Return from function depending on number of parameters
4 Temmuz 2020 Cumartesi tarihinde pepa65 yazdı: > On 04/07/2020 04.39, Lawrence Velázquez wrote: > > It might tell you something that $[...] is not even mentioned in > > the man page for bash 3.2.57, which is decidedly not the current > > version. > > About that, is it for sure that $[] is going to be obsoleted/removed in > the future? I happened to use it recently, and thought it was more > readable than $(()) and caused less visual clutter. Any reason $(()) was > preferred? > > $(()) is the standard syntax for arithmetic expansion. See https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04 Peter > > > -- Oğuz
Re: Return from function depending on number of parameters
On 03/07/2020 10:39 pm, Lawrence Velázquez wrote: On Jul 3, 2020, at 2:00 PM, Chris Elvidge wrote: However 'N=0; echo $((!$N))' gives an error at the bash prompt. 'echo $[!$N]' echo's 1 as expected. My question - is $[...] actually obsolete? It might tell you something that $[...] is not even mentioned in the man page for bash 3.2.57, which is decidedly not the current version. If so, what should I use at the bash prompt to get the same effect? I expect that the error you encountered was caused by !$ expanding to the last word of the previous command and making the contents of $((...)) an invalid arithmetic expression. This didn't affect your scripts because history expansion is not enabled in non-interactive shells by default. Try inserting a space. $ N=0; printf %s\\n "$((! $N))" 1 You can even drop the $. $ N=0; printf %s\\n "$((! N))" 1 vq Thanks for the suggestion. -- Chris Elvidge England
Re: Return from function depending on number of parameters
On 03/07/2020 11:16 pm, Eli Schwartz wrote: On 7/3/20 2:00 PM, Chris Elvidge wrote: I've used 'return $((!$#))' and 'return $[!$#]' to return an error if no parameters given to function. Tested in a bash script 'exit $((!$#)) / $[!$#]' - both work. 'echo $((!$#)) / $[!$#]' - both echo 1 when no params, 0 when any number of params. I'm told ( https://wiki.bash-hackers.org/scripting/obsolete ) that $[...] is obsolete and that $((...)) should be used instead. OK so far. However 'N=0; echo $((!$N))' gives an error at the bash prompt. 'echo $[!$N]' echo's 1 as expected. "gives an error" is a useless bug report. It works for me. $ N=0; echo $((!$N)) 1 My initial reaction to reading this thread is head scratching! As the other reply mentioned, there's actually a good explanation for why we get different results -- I disabled an annoying feature. $ set -o histexpand Now here's a useful bug report. "When I run this, I get the following incorrect results or error message": $ N=0; echo $((!$N)) N=0; echo $((histexpandN)) 0 $ N=0; echo $((!$N)) N=0; echo $(()N)) -bash: syntax error near unexpected token `)' $ N=0 $ echo $((!$N)) echo $((N=0N)) -bash: N=0N: value too great for base (error token is "0N") ... From there, people can give useful advice for solving the problem. (My preferred advice is "disable histexpand".) Thanks for the info on histexpand and the advice on bug reporting. Obviously I didn't read the manual - I didn't know about histexpand. Should that be 'set +o histexpand' to turn it off? -- Chris Elvidge England
Re: Return from function depending on number of parameters
> On Jul 4, 2020, at 8:12 AM, pepa65 wrote: > > On 04/07/2020 04.39, Lawrence Velázquez wrote: >> It might tell you something that $[...] is not even mentioned in >> the man page for bash 3.2.57, which is decidedly not the current >> version. > > About that, is it for sure that $[] is going to be obsoleted/removed in > the future? Only Chet knows for sure, but "obsolete" need not mean "removed". Given how thoroughly it's been memory-holed, $[...] is about as obsolete as it can get. Removing it would break a lot of old scripts, though. > I happened to use it recently Inadvisable. > and thought it was more readable than $(()) and caused less visual > clutter. Any reason $(()) was preferred? Quoting Chet liberally from https://lists.gnu.org/archive/html/bug-bash/2012-04/msg00034.html: > On 4/7/12 4:45 PM, Linda Walsh wrote: > >> In modifying some released code on my distro,I ran into the extensive use >> of $[arith] as a means for returning arithmetic evaluations of the >> expression. >> >> I vaguely remember something like that from years ago, but never see any >> reference to >> it -- yet it works, and old code seems to rely on it -- and >> "$[(1+2)/3]" looks cleaner than "$(((1+2)/3))". So what's up with that? > > It dates from Posix circa 1990 (1003.2d9, of which I've lost my paper > copy). I implemented it after the Berkeley guys, mostly Marc > Teitelbaum, put it into Posix. It ended up getting dropped in favor > of the ksh $((...)) expansion, at which point everyone deprecated the > old $[...]. I removed it from the manual sometime later, but it still > works as it always has. vq
Re: foo | tee /dev/stderr | bar # << thanks!
Hi Lawrence: On Fri 7/3/20 14:03 -0400 =?utf-8?Q?Lawrence_Vel=C3=A1zquez?= wrote: >What's wrong with `foo | tee /dev/stderr | bar`? Perfect! This morning I had thought of foo | tee >(cat >&2) | bar but your soln is simplier. I assume /dev/stderr is on non linux UNIX also. -- thanks-you!, Tom -- $ seq 5 | tee /dev/stderr |tail -2 1 2 3 4 5 4 5
Re: Return from function depending on number of parameters
On 7/4/20 7:54 AM, Chris Elvidge wrote: > On 03/07/2020 11:16 pm, Eli Schwartz wrote: >> On 7/3/20 2:00 PM, Chris Elvidge wrote: >>> I've used 'return $((!$#))' and 'return $[!$#]' to return an error if no >>> parameters given to function. >>> >>> Tested in a bash script 'exit $((!$#)) / $[!$#]' - both work. >>> >>> 'echo $((!$#)) / $[!$#]' - both echo 1 when no params, 0 when any >>> number of params. >>> >>> I'm told ( https://wiki.bash-hackers.org/scripting/obsolete ) that >>> $[...] is obsolete and that $((...)) should be used instead. OK so far. >>> >>> However 'N=0; echo $((!$N))' gives an error at the bash prompt. 'echo >>> $[!$N]' echo's 1 as expected. >> >> "gives an error" is a useless bug report. It works for me. >> >> $ N=0; echo $((!$N)) >> 1 >> >> My initial reaction to reading this thread is head scratching! >> >> As the other reply mentioned, there's actually a good explanation for >> why we get different results -- I disabled an annoying feature. >> >> $ set -o histexpand >> >> Now here's a useful bug report. "When I run this, I get the following >> incorrect results or error message": >> >> $ N=0; echo $((!$N)) >> N=0; echo $((histexpandN)) >> 0 >> $ N=0; echo $((!$N)) >> N=0; echo $(()N)) >> -bash: syntax error near unexpected token `)' >> $ N=0 >> $ echo $((!$N)) >> echo $((N=0N)) >> -bash: N=0N: value too great for base (error token is "0N") >> >> ... >> >> From there, people can give useful advice for solving the problem. (My >> preferred advice is "disable histexpand".) >> > > Thanks for the pointers to a better bug report. > And thanks for the info on histexpand. I obviously should read the > manual more carefully - I'd never come across it - as it's set by > default, not in any profile or bashrc file. It's the section "HISTORY EXPANSION", and set -o histexpand is equivalent to set -H, which controls this option. Many people first realize it exists only when they've been bitten by it. :) > Did you mean set +o histexpand to disable the feature? "set +o histexpand" is in my bashrc to disable the feature. "set -o histexpand" is what I used at the console to temporarily re-enable it, in order to reproduce your issue. As you can see from $ N=0; echo $((!$N)) N=0; echo $((histexpandN)) 0 the first history expansion inserted the word "histexpand" into my command, because the previous command used the word. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
