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 via
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 run
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 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 lo
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
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
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 metho
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.
O
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 2009-
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.
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, non-standa
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 shell.
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.
And
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 (sometime
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:
> >
> > - printable_
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 kee
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 t
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 $'foo
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 s
Clark Wang wrote:
> # echo $'foo'# press ESC C-e
> # echo $foo
+ the same with $"foo".
signature.asc
Description: PGP signature
20 matches
Mail list logo
