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 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
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 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 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
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
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
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
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 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
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
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
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
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
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
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
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
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
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 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
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 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 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
23 matches
Mail list logo