Re: Conditions with logical operators and nested groups execute "if" and "else"

2018-05-31 Thread PePa
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

Redirect to variable

2018-05-20 Thread PePa
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

Re: important bug

2018-03-28 Thread PePa
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

Re: docs incorrectly mention pattern matching works like pathname expansion

2018-03-15 Thread PePa
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

Re: docs incorrectly mention pattern matching works like pathname expansion

2018-03-15 Thread PePa
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

Feature idea

2017-11-27 Thread PePa
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

Re: $"\t': Bash bug or not?

2017-11-17 Thread PePa
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

2017-10-08 Thread PePa
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

Re: RFE & RFC: testing executability

2017-10-02 Thread PePa
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

Re: extension of file-test primitives?

2017-08-19 Thread PePa
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

Re: people working in Greg's locale (+euro) & display of Unicode names

2017-06-15 Thread PePa
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

Re: people working in Greg's locale (+euro) & display of Unicode names

2017-06-14 Thread PePa
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

Re: Trailing newlines disappear

2017-06-09 Thread PePa
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

Re: Trailing newlines disappear

2017-06-08 Thread PePa
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

Trailing newlines disappear

2017-06-08 Thread PePa
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...

2017-06-06 Thread PePa
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

Re: RFE: Please allow unicode ID chars in identifiers

2017-06-03 Thread PePa
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

Re: Why two separate option namespaces?

2017-02-26 Thread PePa
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

Bug? Explanation??

2016-12-30 Thread PePa
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??

2016-12-29 Thread PePa
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

Re: Assigning to BASHPID fails silently

2016-10-20 Thread PePa
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

Anomaly

2016-09-21 Thread PePa
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