Clark Wang wrote:
> # echo $'foo'# press ESC C-e
> # echo $foo
+ the same with $"foo".
signature.asc
Description: PGP signature
Date:Wed, 01 Jul 2020 20:00:23 +0200
From:Andreas Schwab
Message-ID: <871rlvcdzc@igel.home>
| But it also says:
|
| If command is not found, the exit status shall be 127. If command is
| found, but it is not an executable utility, the exit status
On 7/1/20 8:48 AM, Clark Wang wrote:
> See the following example (tested with bash 5.0.7):
>
>
> # bind -q shell-expand-line
> shell-expand-line can be invoked via "\e\C-e".
>
> # echo $PWD # press ESC C-e
> # echo /root
>
> # echo $( pwd ) # press ESC C-e
> # echo /root
>
> # echo
On 7/1/20 2:18 PM, Godmar Back wrote:
> I did a little experiment, changing find_process to assert that SIGCHLD is
> blocked (like the accompanying comment demands).
> This fails on one of the provided unit tests for me, for instance:
Thanks. I think it's possible for a SIGCHLD to arrive during
On 7/1/20 2:01 PM, Robert Elz wrote:
> The lack of an easy method to force execution of a command from the
> filesystem is very likely because there is generally no reason to do
> that. That is, no-one ever really wanted it, so no method was invented.
>
> However, for whatever reason, people
On Wed, Jul 1, 2020 at 10:58 AM Chet Ramey wrote:
>
> > Looking at the bash 5.0 code, I see some comments in the code about
> > strategies to protect the jobs array and other data structures from
> > arriving SIGCHLD signals, but I have questions about, for instance,
> these:
> >
> > -
Date:Wed, 01 Jul 2020 18:45:07 +0300
From:Dmitry Alexandrov
Message-ID:
| One could argue, that an ability to ignore builtin utilities actually adds
| nothing to applicability of a script to different (unknown a priory)
| environments.
One can indeed
On Jul 02 2020, Robert Elz wrote:
> POSIX says:
>
> If command is specified, exec shall not return to the shell;
But it also says:
If command is not found, the exit status shall be 127. If command is
found, but it is not an executable utility, the exit status shall be
126.
On Thu, Jul 02, 2020 at 12:46:33AM +0700, Robert Elz wrote:
> POSIX says:
>
> If command is specified, exec shall not return to the shell;
>
> but in bash...
>
> bash
> jinx$ echo $$
> 23361
> jinx$ exec :
> bash: exec: :: not found
> jinx$ echo $$
> 23361
You're in an interactive
Date:Wed, 01 Jul 2020 18:29:46 +0300
From:Dmitry Alexandrov
Message-ID:
| Well, I am not sure whether it's guaranteed, but the "exec"
| as above does execute an external command in GNU Bash.
Yes, I know, but the way exec works in bash is broken (well,
On Wed, Jul 01, 2020 at 07:21:04PM +0200, felix wrote:
> Again, I use this for not only with `date` and `bc`, but with `mysql`, `ftp`
> or even `ssh` too.
You're like the poster child for Expect.
Thanks Pierre,
On Sun, Jun 28, 2020 at 10:48:42PM +0200, Pierre Gaston wrote:
> Maybe "coproc" is already the feature you need (limited to only 1 though)?
Correct: I missed this!
This work fine:
coproc stdbuf -o0 date -f - +%s 2>&1
DATEIN=${COPROC[1]} DATEOUT=$COPROC
echo >&$DATEIN
Robert Elz wrote:
> The whole point of trying to find a technique like was hoped for using
> command, and others have used env for, and still others, (exec command) (none
> of which are guaranteed to work) is so that the script will work with
> different shells and in different environments.
On 7/1/20 11:29 AM, Dmitry Alexandrov wrote:
> Robert Elz wrote:
>> | > If you need to ensure a disk executable is used,
>> | Of course. Why "command" otherwise?
>>
>> That doesn't actually work, "command" can run built-ins
>
> Ah, yes, thanks for correction.
>
>> there is actually no
Robert Elz wrote:
> | > If you need to ensure a disk executable is used,
> | Of course. Why "command" otherwise?
>
> That doesn't actually work, "command" can run built-ins
Ah, yes, thanks for correction.
> there is actually no method ‹…› which guarantees execution of an executable
> from
Date:Wed, 1 Jul 2020 07:54:05 -0400
From:Eli Schwartz
Message-ID: <511886e8-2262-39ee-2a01-7d284e981...@archlinux.org>
| Indeed -- that's why I specifically used the bashism $(type -P ...) as
| type -P forces the printing of an external file executable.
Yes, saw
On 6/30/20 4:28 PM, Godmar Back wrote:
> Hi,
>
> I'm trying to understand what approach bash takes to async-signal safety in
> its design.
I'm always interested in this kind of analysis, since signal handling
conflicts can be a ripe source of deadlocks -- think glibc and its dozens
of internal
See the following example (tested with bash 5.0.7):
# bind -q shell-expand-line
shell-expand-line can be invoked via "\e\C-e".
# echo $PWD # press ESC C-e
# echo /root
# echo $( pwd ) # press ESC C-e
# echo /root
# echo $'foo'# press ESC C-e
# echo $foo
Is this a bug?
-clark
On 7/1/20 6:24 AM, Robert Elz wrote:
> Date:Wed, 01 Jul 2020 00:43:14 +0300
> From:Dmitry Alexandrov
> Message-ID:
>
> | > If you need to ensure a disk executable is used,
> | Of course. Why "command" otherwise?
>
> That doesn't actually work, "command" can
Date:Wed, 01 Jul 2020 00:43:14 +0300
From:Dmitry Alexandrov
Message-ID:
| > If you need to ensure a disk executable is used,
| Of course. Why "command" otherwise?
That doesn't actually work, "command" can run built-ins, there is
actually no method (not even
20 matches
Mail list logo
