Re: Conditions with logical operators and nested groups execute "if" and "else"
On 05/31/2018 01:54 PM, Robert Elz wrote: > I am not sure what predence rule you see working as > expected, but in sh (bash, or any other Bourne syntax > or POSIX shell) there is no precedence for && and || > they (in the absense of grouping) are simply executed > left to right as written. Here is an easy way to figure out how and/or-lists work: Given that && and || have the lowest precedence of all operators (except for ; and &), they can be thought of as concatenating commands/blocks/pipelines, and the execution rule for an and/or-list is: If the exit-status of the command/block/pipeline is 0, continue after the next &&, otherwise continue after the next || in the and/or-list. Cheers, Peter
Redirect to variable
I would like to do something like this, where output gets redirected into a variable: some-command >>> variablename1 2>>>variablename2 command-with-many-output-descriptors >>> var1 3>>> var3 4>>> var4 The idea is not needing files to be created but to just use memory. Half a year ago I posted this idea here, but didn't get any reply, maybe this isn't the right place? Am I blacklisted?? Anyway, I keep using bash. Cheers, Peter
Re: important bug
I didn't understand clearly what you were expecting until I actually ran
your example. I think this shows your expectations more clearly:
test a = a && {
echo this line should be displayed
test a = b && {
echo this line should not be displayed and is not
}
# echo uncomment this line and the last echo will not display
} || {
echo this line should never be displayed but is
}
The "test a = b" evaluates to false, which makes the whole enclosure
after "test a = a" also false, and now the last echo will display. The
uncommented echo will make the middle clause true again, causing the
last echo to not display (as expected).
Peter
Klaus Bartels
On 03/29/2018 01:22 AM, Klaus Bartels wrote:
> If you execute the following script the result is wrong. It is self
> explaining:
> ---
> #
> # GNU bash, version 4.4.12(1)-release (x86_64-slackware-linux-gnu)
> # Linux ... 4.9.31 #1 SMP Wed Jun 7 14:57:36 CDT 2017 x86_64 Intel(R)
> Core(TM) i5-7400 CPU @ 3.00GHz GenuineIntel GNU/Linux
> #
> test a = a && {
> echo this line should be displayed
> test a = b && {
> echo this line should also not displayed, but creates the error
> }
> # echo uncomment this line and all works fine again
> } || {
> echo this line should never be displayed
> }
> #
> --
> If you uncomment the line in the middle, the script works correct.
> I hope, it helps
>
>
>
> Mit freundlichen Gruessen / Best regards
> Klaus Bartels
>
> ///-///
> /// Bartels EDV (Bartels Consulting) ///
> /// Klaus Bartels ///
> /// Am Bullerbach 11 Phone +49-5484/93 91 0 ///
> /// D-49536 Lienen FAX +49-5484/93 91 16 ///
> /// Germany e-Mail bart...@bartels.com ///
> ///-///
>
Re: docs incorrectly mention pattern matching works like pathname expansion
I think bash's echo does this, it doesn't do the pattern matching like case, the slashes need to be there. You might need/want `shopt -s dotglob nullglob` Peter On 03/16/2018 05:52 AM, Stormy wrote: > ok, thanks for the confirmation. now u see what I meant before.. when saying > bash does not have a builtin way to call fnmatch (I meant: for path name > matching), clearly bash calls fnmatch, that is obvious, but there is no way > to make it do pathname matching internally. (cd, ls, will surely do it, > external to bash though).. > > anyways, thanks for all the help.. > > > On Thursday, March 15, 2018, 9:44:38 PM GMT+2, Chet Ramey > wrote: > > On 3/15/18 3:26 PM, Stormy wrote: > >> like I said, I've already implemented, roughly 40 lines in bash, and it >> seems to work, but if there is some builtin option 'shopt' or similar that >> can turn the right flags you mentioned, I'm all for testing it :) > > There isn't. Pathname expansion is done in the specific circumstances Posix > says it should be (and historical shells perform). The other contexts use > straight pattern matching. > >
Re: docs incorrectly mention pattern matching works like pathname expansion
It is clear that the matching in 'case' does general pattern matching but not pathname matching. I think the bash man page should say so, clearly distinguishing different ways of matching in bash. Peter On 03/15/2018 11:15 PM, Stormy wrote: > Thanks for the reply. I'm not sure we are talking about the same thing.. > maybe..does this example help? > # case /test/test2/dir1/file in /test/*) echo 'match';; *) echo 'nomatch';; > esac > match > > here, the expectation is to NOT match, since '/test/*' in normal shell, i.e. > "ls", would NOT match that long path. by path name expansion, man page is > hinting it behaves like "ls", but clearly it does not. > in summary, it seems bash has no internal fnmatch(3) implementation. > > > On Thursday, March 15, 2018, 5:26:32 PM GMT+2, Chet Ramey > wrote: > > On 3/14/18 1:43 PM, Stormy wrote: > >> Bash Version: 4.2 >> Patch Level: 46 >> Release Status: release >> >> Description: >> Section of 'case' in bash's man page says: >> >> case word in [ [(] pattern [ | pattern ] ... ) list ;; ] ... esac >> A case command first expands word, and tries to match it >> against each pattern in turn, using the same matching >> rules as for pathname expansion (see Pathname Expansion below). >> >> but that is not correct, the matching here does NOT follow pathname >> expansion, the treatment of "/" is not the same. > > The description of Pathname Expansion says, in part: > > "When matching a > pathname, the slash character must always be matched explicitly." > > but I can expand that to also say that it other contexts it does not need > to be. > >
Feature idea
Recently I wanted to put the content of the stdout and the stderr of a command into variables (without needing to write to a file), something like this: sterr=$(cmd >>>stout) Or: stout=$(cmd 2>>>sterr) Or even: cmd >>>stout 2>>>sterr Obviously the idea is to introduce an operator >>> that functions as a "reverse here-document" that stores the content of a file stream into a variable. There would be less need to store things in a file on a filesystem. I think that would be very useful extension, easy to comprehend in the light of current syntax, and not clashing with anything as far as I can see. Thanks for considering this, Peter
Re: [here string] uncompatible change on here string function
On 11/23/2017 02:23 AM, Chet Ramey wrote: The bash-4.2 man page defers the description of here strings to the description of here documents. The lines in a here document do not undergo word splitting. It was a bug in bash-4.2 that the WORD in a here string was split. This finally got fixed in bash-4.4, as described by this CHANGES entry: z. Bash no longer splits the expansion of here-strings, as the documentation has always said. I would think it is useful (and according to how things work in general) to have a different behavior for <<<"$a" and <<<$a If one wants to have all line-breaks, spaces and tabs preserved, use <<<"$a" otherwise use <<<$a Peter
Re: $"\t': Bash bug or not?
On 11/15/2017 11:06 PM, Greg Wooledge wrote: On Wed, Nov 15, 2017 at 09:01:52AM -0600, Rick Richardson wrote: tab=$'\t' echo "$tab " | xod Where can I get xod? I tried looking here https://github.com/xodio/xod and I found a perl script that couldn't be piped into. Peter
Re: Bash handling of ENOENT on missing files and directories
On 10/09/2017 05:30 AM, Jonny Grant wrote: Fair enough. I agree it has been around for longer, but meant that POSIX standardized on that limitation, and didn't offer a better solution that clarified, eg ENOENTF ENOENTD I'm guessing not making the distinction saved a bit of CPU. yes, a clearer errno value, for files, and separate for directories would be ideal. Would have been better. Has anyone ever wanted to "cd" into a file? $ cd file -bash: cd: file: Not a directory In this case it tested whether 'file' is a directory. When trying 'cd' into 'missingdir', the result is that an entry 'missingdir' couldn't be found, whether file or directory. This is actually more informative. Peter
Re: RFE & RFC: testing executability
On 10/01/2017 11:31 AM, L A Walsh wrote: cmd=$(PATH=/stdpath type -p cmd) I use this kind of construction with 'type -p' regularly: ! cmd=$(type -p cmd) && echo "ABEND: Executable cmd not in PATH" && exit Then $cmd can be used to execute the binary, and not some alias or function. This is the whole point of the '-p' flag, otherwise you would use the '-a' flag. When 'cmd' is in the PATH, it is found even when it isn't executable, so it could make sense to do 'text -x "$cmd". > the "-x" test failed if cmd was an alias, function or preceded by > 'command' (which I was surprised, also, to find, "not executable"). Note that 'test -x' only tests actual files, so if you do 'test -x grep' and there is no executable file 'grep' in $PWD then it tests false. > Comments? Reasonable? Wanted? Doable or patchable? It follows that you cannot use 'test -x' on functions or aliases, as they are not files. I don't understand your use case. Do you want a 'type -a' kind of functionality? What do you want to test?? I think you can already do what you need in bash. Peter
Re: extension of file-test primitives?
In that case, would not [[ =fx $file ]] be more workable and in line
with common GNU short commandline option practice??
Peter
On 08/20/2017 07:30 AM, L A Walsh wrote:
Curious, but how difficult or problematic would it be
to allow using brace-expansion (ex. {f,x} ) as a short-hand
to test/combine file-op tests like:
Allowing:
test -{f,x} /bin/ls && ...
or
if [[ -{f,x} $file ]]; then ... ; fi
instead of:
test -f /bin/ls && test -x /bin/ls && ...
??
(maybe boring background):
Came from a spur-of-the-moment experimenting with bash equivalents
to perl's file-op chaining, like:
if (-f -x "/bin/ls") { ... }
and came up with something a bit odd but working, but
a bit quirky looking for a lib-type function or alias:
eval 'test -'{f,x}' /bin/ls && :' && echo executable file
and wondered if bash might adopt some shortcut for testing
multiple flags or if it was too specialized for such a minor
optimization...
just a minor curiosity if code was submitted...etc...etc...?
Re: people working in Greg's locale (+euro) & display of Unicode names
On 15/06/2560 22:03, Chet Ramey wrote: > I don't know other languages well enough to point one out, but I can easily > imagine that a particular character is an "alphabetic" in, say, Mandarin, > but doesn't exist in someone's en_US character set. I though you were referring to a character existing in both sets. This is the reason why I think you should only concern yourself with characters that already have an established semantic in bash. Don't get bogged down in distinguishing classes in myriads of character sets. Just allow anything that isn't ASCII (but IS UTF-8 -- I'm talking about UTF-8, otherwise this discussion becomes impossible). > I see a number of problems with using non-alphanumerics in shell > identifiers. The real advantage to allowing this is to allow users to > put alphabetics from their own locales into shell identifiers. There's > little reason to do it otherwise, and plenty of complications. What are those problems and complications?? > As for the implementation, it's much easier to use isalpha/isdigit (and > their wide character equivalents) than to try and keep track of a blacklist > of characters across different locales. I don't propose blacklists across locales, just blacklisting what already has an established meaning in bash, ie. ASCII. All the rest is just fair game, if someone insists on using a thumbs-up icon in a variable name, why restrict that?? The restricting and policing is going to make this costly in terms of developer time and CPU time. Peter
Re: people working in Greg's locale (+euro) & display of Unicode names
On 15/06/2560 07:13, Chet Ramey wrote: > A character that is classified as an alphanumeric in a particular locale, > but not in another, can lead to portability problems. That's what we're > debating here, not how something gets displayed in a text editor. I don't think that exists in unicode or UTF-8 -- could you give an example of a character that is classified as an alphanumeric in a particular locale, but not in another? I think this whole discussion about alphanumerics in world languages is a red herring though. I don't see any objection in using any symbol/glyph as admissible in variable names, barring certain reserved ASCII ones, like space, comma, dot, dash, several kinds braces etc. It would also greatly simplify the whole implementation. Peter
Re: Trailing newlines disappear
On 09/06/2560 19:06, Greg Wooledge wrote:
> imadev:~$ a=$(printf 'foo\0bar\nbaz\nquux\n'; printf x) a=${a%x}
> bash: warning: command substitution: ignored null byte in input
> imadev:~$ declare -p a
> declare -- a="foobar
> baz
> quux
> "
>
> imadev:~$ IFS= read -rd '' a < <(printf 'foo\0bar\nbaz\nquux\n')
> imadev:~$ declare -p a
> declare -- a="foo"
>
> imadev:~$ unset a
> imadev:~$ mapfile -t a < <(printf 'foo\0bar\nbaz\nquux\n')
> imadev:~$ declare -p a
> declare -a a=([0]="foo" [1]="baz" [2]="quux")
That is good to realize. I guess languages that strive for improvements
and yet backward comparibility over many years just end op being arcane!
Peter
Re: Trailing newlines disappear
On 09/06/2560 02:14, Greg Wooledge wrote:
> Well, it leaves IFS changed, because you didn't revert or unset it,
> or run the entire thing in a function with local IFS. Also, I'd use
> "${MAPFILE[*]}" to reinforce that you are joining an array into a string,
> rather than expanding the array as a list.
Thanks for pointing all this out. I settled on:
mapfile <"$file"; IFS= foo=${MAPFILE[*]} true
Again, much faster than a subshell. Are there order guarantees in the
case of "a=x b=y command"??
Peter
Trailing newlines disappear
I would think this is a bug: 4.3.48(1)-release> printf "q\n\n\n" >w 4.3.48(1)-release> cat w q 4.3.48(1)-release> printf "$(cat w)" q 4.3.48(1)-release> Is there some workaround to somehow preserve the trailing newlines? Peter
Re: Patch for unicode in varnames...
On 06/06/2560 21:20, Greg Wooledge wrote: > Scripts that can only *run* in a UTF-8 encoding-locale are a bad idea. Even currently, when functions in a bash script are beyond ASCII, they can still be run anywhere. I would imagine it would be the same when variable names are also allowed to be in some unicode encoding. Editing them might be more difficult -- even when your editor renders the script correctly, as the names might not make sense to you. It might help people with other native languages though. The net loss to you is less than the potential gains for people that want it. And remember, function names could already be in a strange script..! There is a precedent, and it would make sense to enhance the support to those that desire it. But I don't think you need to be too afraid, I've never encountered a bash script with function names in non-ASCII characters. (But who knows, in some domains that we would not very easily encounter it is already prevalent..?) Peter
Re: RFE: Please allow unicode ID chars in identifiers
On 04/06/2560 01:00, George wrote: > There's a series of trade-offs between keeping the implementation relatively > simple vs. supporting equivalency where the user may reasonably expect > it. I will personally never use non-ascii in a bash script, even though I use unicode extensively, also in the shell. But the fact that unicode functions are already supported does seem to pave the way for allowing variable names in unicode. For consistency, it should really be the same handling as function names -- I am expecting no equivalency support in the current function name implementation, and I am also guessing that many types of non-ascii space are also allowed in function names already. Which does makes sense: if people want to shoot themselves in the foot by using similar/same looking but actually different glyphs and spaces, it would be too tiresome to try to prevent that. Peter
Re: Why two separate option namespaces?
Sounds like a useful proposal with little (no?) downsides..! Peter On 27/02/2560 13:08, Martijn Dekker wrote: > It is not clear to me why bash has two separate namespaces for > long-named shell options, handled by two separate commands. > > It might make sense if 'set -o' is for POSIX options only and 'shopt' > for bash-specific options, but that doesn't apply. I can't figure out a > consistent basis for a distinction. This makes it a bit of a pain to > remember which option goes with which command, e.g. that 'pipefail' goes > with set, but 'lastpipe' goes with shopt. > > What was the original reason behind this? > > Since there currently are no naming conflicts between the two > namespaces, would there be any disadvantage to simply merging them and > allowing all options to be manipulated using either set or shopt? > > Thanks, > > - M. >
Bug? Explanation??
It seems that when piping into bash, variables have different
'retention' than functions:
r=23; echo $r; echo -e "r=bc\necho $r" |bash
23
23
r(){ echo Hey;}; r; echo -e "r(){ echo Ho;}\nr" |bash
Hey
Ho
Is this a bug, or is there a rationale?
Thanks,
Peter
Re: BUG??
Of course... My own stupidity. It did raise the question for me, what would be the recommended way to 'group' expressions, where other languages would use brackets, like: if (((q==1)) || [[ $r ]]) && grep -q $s $file then echo "$s is in $file, and either q is 1 or r is not empty" fi I guess this works, but it spawns a subshell. Is there a better way? Thanks, Peter On 29/12/2559 08:38, Chet Ramey wrote: > On 12/28/16 8:09 PM, Peter & Kelly Passchier wrote: >> Is this a bug? These both output "q=1" >> >> q=1 >> [[ ((q==1)) ]] && echo q=1 >> >> q=0 >> [[ ((q==1)) ]] && echo q=1 >> > > No. These both end up checking whether the length of the string "q==1" is > non-zero, which it is. >
Re: Assigning to BASHPID fails silently
Picking 2 allows old scripts that work to keep working. Changing to 1 would change the functionality of formerly working scripts in very undesirable ways. ;-) > 1. BASHPID is readonly, therefore assignment to it is fatal and the script > exits > (with an error message printed). That's what my previous patch did. > > 2. BASHPID is not read-only, but changes to it are discarded (with the null > assignement function). Assignments to BASHPID are non-fatal, and it's possible > to unset it. Once it's unset, it's magical meaning is lost. (I think this is > what Chet is proposing). noro_bashpid.patch > >> In what possible context would assigning to any of these variables make >> sense, or be an indication of anything other than a fatal bug in the >> script? I think they should all be readonly, and produce a proper >> diagnostic error message upon exit if assigning is attempted. > [...] > > I wonder the same thing. I don't understand the reasoning for picking (2). >
Anomaly
When sourcing this script (version 1), it will print y after receiving an interrupt, but not in the 2 different versions (2 and 3). # version 1 echo x sleep 99 echo y # version 2 echo x; sleep 99 echo y # version 3 echo x sleep 99; echo y Is this a bug or expected behaviour?? Thanks for your attention, Peter
