Coprocess FD not available when duplicated to FD other than 1 or 2
The following correctly prints "fd=2":
coproc p { head -1; }
2>&${p[1]} bash -c 'echo fd=2 >&2'
cat <&${p[0]}
Change 2 to 3, throws error: "bash: 3: Bad file descriptor":
coproc p { head -1; }
3>&${p[1]} bash -c 'echo fd=3 >&3'
cat <&${p[0]}
I'm not very familiar with redirection, so I may have overlooked
something obvious...
What am I missing?
Re: Assigning to BASHPID fails silently
On 10/17/16 2:38 PM, Martijn Dekker wrote: > bash 4.4.0 (I did not investigate other versions) does not produce an > error message if you try to assign something to the BASHPID readonly > using either arithmetic or normal assignment. Other readonlies produce a > message on an assignment attempt. BASHPID seems to be an exception. BASHPID is a dynamic variable. There should be a sentence in the man page that says assignments to it have no effect (as it does for GROUPS and FUNCNAME, for example). It probably should not be readonly, though it has been marked as such in previous versions of bash. I will fix the man page first. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: TIMEFORMAT in time ( )
On 10/16/16 6:01 PM, isabella parakiss wrote:
> $ cat myscript
> TIMEFORMAT=foo var=x
>
> time ( TIMEFORMAT=bar var=y )
> echo "<$TIMEFORMAT> <$var>"
>
> f() { TIMEFORMAT=f; time :; }
> time ( f )
> echo "<$TIMEFORMAT>"
>
>
> $ bash myscript
> bar
>
> f
> f
>
>
>
>
> setting TIMEFORMAT in ( ) affects time out of the subshell
> this cannot be right
The difference is that `time' is not a command or a builtin; it is a shell
reserved word that sets a property of the command following it. In this
case, that means that the timing information is printed -- in the command's
context -- after it completes. That's why the timing property accompanies
a command, like the subshell, when it is executed, and why the code is
ordered the way it is.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Coprocess FD not available when duplicated to FD other than 1 or 2
On 10/19/16 8:24 AM, lolilolicon wrote:
> The following correctly prints "fd=2":
>
> coproc p { head -1; }
> 2>&${p[1]} bash -c 'echo fd=2 >&2'
> cat <&${p[0]}
>
> Change 2 to 3, throws error: "bash: 3: Bad file descriptor":
>
> coproc p { head -1; }
> 3>&${p[1]} bash -c 'echo fd=3 >&3'
> cat <&${p[0]}
>
> I'm not very familiar with redirection, so I may have overlooked
> something obvious...
>
> What am I missing?
File descriptors greater than 2 are set to close-on-exec in child
processes.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: How bash do tokenization?
OK. I see it, which check emails and print prompt. What factors people need to consider to decide whether to use flex to perform tokenization and write a customize tokenizer? Checking emails and printing prompt strictly speaking is not related with tokenization. Is there an alternative way to organize the code so that it will be more decoupled? On Tue, Oct 18, 2016 at 10:22 PM, Eduardo Bustamante wrote: > On Tue, Oct 18, 2016 at 10:18 PM, Eduardo Bustamante > wrote: >> Check parser.y > Sorry, I meant parse.y, inside it you will find read_token and yylex. -- Regards, Peng
bash history / ssh+sudo+reverse-i-search will execute the command found if the ssh process is killed
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS -DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin' -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic uname output: Linux server1 3.10.0-327.18.2.el7.x86_64 #1 SMP Fri Apr 8 05:09:53 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 4.2 Patch Level: 46 Release Status: release Description: Bash history / reverse-i-search will execute the command found if the ssh process is killed. This happens with the combination of: - ssh into server - sudo su - - reverse-i-search # +R I.e. a user in the middle of a bash reverse-i-search, and the ssh process is killed i.e. due to a network outage. This can be critical if the command in the search history is something harmful or potentially unwanted, like a server shutdown The chain of events during the kill, and how the sub processes are killed might be the cause here, but nevertheless no signal should cause the bash history command to run. Repeat-By: Pre-requisites: a user with a bash shell Log (SSH) in to a server (server1) On server1 type date > /tmp/file.txt rm /tmp/file.txt On server1 type +R "date" Log in to server1 on a second terminal / ssh window ps -ef | grep kill ls -l /tmp/file.txt The /tmp/file.txt has now been created Verified on (also): Ubuntu 16.04 LTS Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL $ uname output: Linux ubuntu1604 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12 13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.3 Patch Level: 46 Release Status: release Bash Version: 4.3 Patch Level: 46 Release Status: release CentOS Linux release 7.2.1511 (Core) === Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS -DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin' -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic uname output: Linux centos7 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 4.2 Patch Level: 46 Release Status: release Unable to reproduce with: - Local gnome terminal + bash in ubuntu - ssh to a user in two terminals, repeat steps and kill the second terminal It seems that there is something happening when killing the sshd process in combination with sudo -- Stein Arne Storslett
Re: Assigning to BASHPID fails silently
Op 19-10-16 om 15:18 schreef Chet Ramey: > On 10/17/16 2:38 PM, Martijn Dekker wrote: >> bash 4.4.0 (I did not investigate other versions) does not produce an >> error message if you try to assign something to the BASHPID readonly >> using either arithmetic or normal assignment. Other readonlies produce a >> message on an assignment attempt. BASHPID seems to be an exception. > > BASHPID is a dynamic variable. There should be a sentence in the man > page that says assignments to it have no effect (as it does for GROUPS > and FUNCNAME, for example). Assigning to BASHPID most certainly does have an effect. Since you didn't quote that part, I think you might have missed my point that attempting this will silently exit the shell without any error message, causing the problem to be hard to track down. This is different from GROUPS and FUNCNAME, where the shell silently continues (causing the problem to be hard to track down in a completely different way -- if anything, that's worse!). > It probably should not be readonly, though > it has been marked as such in previous versions of bash. In what possible context would assigning to any of these variables make sense, or be an indication of anything other than a fatal bug in the script? I think they should all be readonly, and produce a proper diagnostic error message upon exit if assigning is attempted. If you're keeping them non-readonly for backwards compatibility reasons, then IMHO that is misguided; assignments silently fail, which is far worse than erroring out. Unsetting GROUPS and FUNCNAME first does work, but it's a rare script that unsets variables before use. Maybe a compromise would be to introduce a semi-readonly state, where unset works but assignments fail. Thanks, - Martijn
Re: Assigning to BASHPID fails silently
On Wed, Oct 19, 2016 at 11:53:37PM +0200, Martijn Dekker wrote:
[...]
> Assigning to BASHPID most certainly does have an effect. Since you
> didn't quote that part, I think you might have missed my point that
> attempting this will silently exit the shell without any error message,
> causing the problem to be hard to track down. This is different from
> GROUPS and FUNCNAME, where the shell silently continues (causing the
> problem to be hard to track down in a completely different way -- if
> anything, that's worse!).
I think he did get your point. There's definitely a bug here. It should be
either:
1. BASHPID is readonly, therefore assignment to it is fatal and the script exits
(with an error message printed). That's what my previous patch did.
2. BASHPID is not read-only, but changes to it are discarded (with the null
assignement function). Assignments to BASHPID are non-fatal, and it's possible
to unset it. Once it's unset, it's magical meaning is lost. (I think this is
what Chet is proposing). noro_bashpid.patch
> In what possible context would assigning to any of these variables make
> sense, or be an indication of anything other than a fatal bug in the
> script? I think they should all be readonly, and produce a proper
> diagnostic error message upon exit if assigning is attempted.
[...]
I wonder the same thing. I don't understand the reasoning for picking (2).
--
Eduardo Bustamante
https://dualbus.me/
diff --git a/variables.c b/variables.c
index 2e8b38c..5120f2e 100644
--- a/variables.c
+++ b/variables.c
@@ -1462,7 +1462,7 @@ get_bashpid (var)
p = itos (pid);
FREE (value_cell (var));
- VSETATTR (var, att_integer|att_readonly);
+ VSETATTR (var, att_integer);
var_setvalue (var, p);
return (var);
}
@@ -1767,7 +1767,7 @@ initialize_dynamic_variables ()
VSETATTR (v, att_integer);
INIT_DYNAMIC_VAR ("BASHPID", (char *)NULL, get_bashpid, null_assign);
- VSETATTR (v, att_integer|att_readonly);
+ VSETATTR (v, att_integer);
#if defined (HISTORY)
INIT_DYNAMIC_VAR ("HISTCMD", (char *)NULL, get_histcmd,
(sh_var_assign_func_t *)NULL);
