Hi,
I assume . command does not search current directory anymore
in bash 4 for a reason. Perhaps it is specified by relevant
standard, although I did not find it.
This incompatible change affects me a lot. I imagine
I am not alone with this.
To forestall questions from users like me, consider
On Mon, Jul 20, 2009 at 3:20 AM, Chet Rameychet.ra...@case.edu wrote:
Denys Vlasenko wrote:
I assume . command does not search current directory anymore
in bash 4 for a reason. Perhaps it is specified by relevant
standard, although I did not find it.
This incompatible change affects me a lot
$ f() { for i; do echo "|$i|"; done; }
$ x=x
$ e=
$ f ${x:+""}
||
^^^ correct
$ f ${x:+ ""}
^^^ prints nothing, bug?
$ ${x:+"" }
^^^ prints nothing, bug?
$ f ${x:+"$e"}
||
^^^ correct
$ f ${x:+ "$e"}
^^^ prints nothing, bug?
$ f ${x:+"$e""$e"""}
||
On 07/20/2018 04:43 PM, Denys Vlasenko wrote:
$ ${x:+"" }
^^^ prints nothing, bug?
Should be:
$ f ${x:+"" }
$ f ${x:+"$e""$e"""}
^^^ prints nothing, bug?
Should be:
$ f ${x:+"$e""$e" ""}
sorry.
Unquoted ${v:+ARG} operator allows single-quoted strings
in ARG:
$ x=a; echo ${x:+'b c'}
b c
In this case, obviously single quotes must be paired.
If ${v:+ARG} is in double-quoted string, single quotes lose their special
status:
$ x=a; echo "${x:+'b c'}"
'b c'
IOW: they work similarly to
Background:
Unquoted heredocs are this construct
cat <
On 2/24/20 5:18 PM, Chet Ramey wrote:
The first case is trickier: there's always going to be a window between
the time the shell checks for pending traps and the time the wait builtin
starts to run. You can't really close it unless you're willing to run the
trap out of the signal handler, which
On 2/24/20 9:59 AM, Robert Elz wrote:
And that is, when the wait/waitpid/wait3/wait4/waitid/wait6 (whatever the
shell uses) system call returns EINTR, the wait utility exited with a
status indicating it was interrupted by that signal (status > 128 means
128+SIGno) and runs the trap.
This is
On Sat, Feb 8, 2020 at 7:41 PM Harald van Dijk wrote:
> I changed gwsh to call sigclearmask() on shell startup, but plan to
> check whether this loop is really necessary at some later time. It was
> added to dash to fix a race condition, where that race condition was
> apparently introduced by a
On 2/21/20 4:07 PM, Chet Ramey wrote:
On 2/21/20 9:44 AM, Denys Vlasenko wrote:
Yes, and here we are "after command", specifically after "{...} &" command.
Since we got a trapped signal, we must run its trap.
Did you look at the scenario in my message?
What
On 2/20/20 4:27 PM, Chet Ramey wrote:
On 2/20/20 3:02 AM, Denys Vlasenko wrote:
On 2/19/20 9:30 PM, Chet Ramey wrote:
On 2/19/20 5:29 AM, Denys Vlasenko wrote:
A bug report from Harald van Dijk:
test2.sh:
trap 'kill $!; exit' TERM
{ kill $$; exec sleep 9; } &
wait $!
The above script o
On 2/19/20 9:30 PM, Chet Ramey wrote:
On 2/19/20 5:29 AM, Denys Vlasenko wrote:
A bug report from Harald van Dijk:
test2.sh:
trap 'kill $!; exit' TERM
{ kill $$; exec sleep 9; } &
wait $!
The above script ought exit quickly, and not leave a stray
"sleep" child:
(1) if &q
A bug report from Harald van Dijk:
test2.sh:
trap 'kill $!; exit' TERM
{ kill $$; exec sleep 9; } &
wait $!
The above script ought exit quickly, and not leave a stray
"sleep" child:
(1) if "kill $$" signal is delivered before "wait",
then TERM trap will kill the child, and exit.
(2) if "kill
According to the source, -R should be setting RLIMIT_RTTIME,
but it does not work:
bash-5.0$ ulimit -R
bash: ulimit: -R: invalid option
ulimit: usage: ulimit [-SHabcdefiklmnpqrstuvxPT] [limit]
..and looking at the above help, I notice letters I never saw.
Lets try them?
bash-5.0$ ulimit -b
Try these two commands:
$ echo "Date: `date #comment`"
Date: Thu Jul 27 10:28:13 CEST 2023
$ echo "Date: $(date #comment)"
)"
Date: Thu Jul 27 10:27:58 CEST 2023
As you see, #comment is handled differently in `` and $().
I think the handling in `` makes more sense.
On 7/28/23 19:51, Martin D Kealey wrote:
On the other hand, since everyone has now had 36+ years to update their scripts
to get rid of backticks,
I don't know about others, but I missed the memo that `` is deprecated.
Please do not break compatibility.
The importance of compatibility is
On 7/31/23 15:07, Chet Ramey wrote:
On 7/31/23 7:38 AM, Denys Vlasenko wrote:
In the spirit of increased compatibility across Unix world, it'd be
quite useful if shells stop inventing incompatible "extensions".
That's an excellent way to stifle innovation.
There is no reason t
Good day.
IIRC bash used to allow numeric constants of the
BASE#DIGITS form even if the DIGITS part was empty.
IOW: not only "64#0", but "64#" too was accepted
as a valid zero constant.
This no longer works in 5.2.15, probably better than
former behavior, "64#" looked quite confusing.
However,
18 matches
Mail list logo
