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
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 th
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 an
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 h
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 ab
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
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 b
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
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
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 th
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/com
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
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 U
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
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 l
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
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 so
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 th
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 o
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
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 th
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 pre
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 at
23 matches
Mail list logo
