Script ends prematurely when fed into bash's stdin
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: i686-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -march=i686 -fomit-frame-pointer uname output: Linux alphaville.zko.hp.com 2.6.12-gentoo-r6 #4 Thu Sep 1 11:04:19 EDT 2005 i686 Intel(R) Pentium(R) M processor 1600MHz GenuineIntel GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 3.0 Patch Level: 16 Release Status: release Description: Consider a script that invokes ssh to execute a remote command (I've set up public key authentication, so no passwords are needed): ssh remote date date ssh remote date date exit 0 If I invoke bash and give it the script filename as argument, it works fine. But if I pipe the script file into bash or redirect bash's stdin so that it comes from the script file, bash quits immediately after the (first) ssh command is finished. stracing the bash invocation shows that bash gets an EOF on the read after the ssh command is done. Although ssh is essential to this behavior, I cannot see how ssh could fiddle with bash's stdin, so I decided to submit is as a bash bug - but I may be wrong. My current workaround is to redirect ssh's stdin from /dev/null: ssh remote date http://lists.gnu.org/mailman/listinfo/bug-bash
Volk wird nur zum zahlen gebraucht!
Lese selbst: http://www.my-rocknord.de/viewtopic.php?t=1018&sid=3ce6385b1dee88cb02447f566a2da68d .. damit Sie nicht als der erste Kanzler in die deutsche Geschichte eingehen, der Untertanen verboten hat, aus ihren Fenstern auf die Strasse zu gucken - selbst Nazis und Stalinisten haben niemals eine aehnliche Anordnung treffen lassen! ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Bug in [ error reporting
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-pc-linux-gnu' -DCONF_VENDOR='pc' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 uname output: Linux client1 2.6.8-2-386 #1 Thu May 19 17:40:50 JST 2005 i686 GNU/Linux Machine Type: i386-pc-linux-gnu Bash Version: 2.05b Patch Level: 0 Release Status: release Description: The [ command error reporting can incorrectly state which file an error occured in. Repeat-By: Create A.sh: #!/bin/sh echo "about to source B.sh" source B.sh echo "finished sourcing B.sh" Create B.sh: #!/bin/sh echo "first line of B.sh. next line has an error.." [ 0 [ echo "after error-line" Run A.sh: [EMAIL PROTECTED]:~> ./A.sh line 3 of A.sh. about to source B.sh line 2 of B.sh. next line has an error.. ./A.sh: line 3: [: missing `]' after error-line finished sourcing B.sh [EMAIL PROTECTED]:~> See that the error message says that the error occured on line 3 of A.sh, when in fact the error occured on line 3 of B.sh -Nick Hoffman [EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
ssh does not source /etc/bash.bashrc, but manual execution of /bin/bash does it under specific circumstances
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-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='$
uname output: Linux katastrofi 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2
(2016-10-19) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.3
Patch Level: 30
Release Status: release
Description:
Hello,
i came up with a weird behavior of ssh+bash on my Debian box (8.6).
I created an alias in /etc/bash.bashrc file, which is sourced through
/etc/profile.
Everything worked fine, till i decided to remove the '.
/etc/bash.bashrc' line from /etc/profile.
When i` m connected via ssh the '/etc/bash.bashrc' is not sourced and
the alias does not work as expected.
But, when i execute bash from my shell, the '/etc/bash.bashrc' seems to
be sourced and the alias is there (please find bellow a demo)
Not sure if i miss something (f.x. bash is executed with different
flags while being called from ssh versus a user), but as far as i understand,
the same things should be (or not) sourced.
Best,
Nick
Please find /etc/bash.bashrc, /etc/profile and my home directory under
this link: www.katastrofi.eu/nick.tar.gz
# Demo
root@RBMK-1000:~# ssh nick@10.250.251.12
ssh nick@10.250.251.12
nick@10.250.251.12's password:
The programs included with the Debian GNU/Linux system are free
software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Dec 20 17:29:37 2016 from 10.250.251.238
bla
nick@RBMK-1000:~$ ll
-bash: ll: command not found
nick@RBMK-1000:~$ bash
nick@RBMK-1000:~$ ll
total 24
drwxr-xr-x 2 nick nick 4096 Dec 20 17:28 .
drwxr-xr-x 3 root root 4096 Dec 13 22:06 ..
-rw--- 1 nick nick 195 Dec 20 17:29 .bash_history
-rw-r--r-- 1 nick nick 220 Nov 4 12:58 .bash_logout
-rw-r--r-- 1 nick nick 3515 Nov 4 12:58 .bashrc
-rw-r--r-- 1 nick nick 675 Nov 4 12:58 .profile
nick@RBMK-1000:~$
# nick login shell
nick@katastrofi:~$ grep nick /etc/passwd
nick:x:1000:1000:,,,:/home/nick:/bin/bash
nick@katastrofi:~$
# OS
nick@RBMK-1000:~$ uname -a
Linux RBMK-1000 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2
(2016-10-19) x86_64 GNU/Linux
nick@RBMK-1000:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 8.6 (jessie)
Release:8.6
Codename: jessie
nick@RBMK-1000:~$
# Packages installed
nick@RBMK-1000:~$ dpkg -l | grep bash
ii bash 4.3-11+b1 amd64
GNU Bourne Again SHell
ii bash-completion1:2.1-4 all
programmable completion for the bash shell
nick@RBMK-1000:~$ dpkg -l | grep ssh
ii libssh2-1:amd641.4.3-4.1+deb8u1amd64
SSH2 client-side library
ii openssh-client 1:6.7p1-5+deb8u3amd64
secure shell (SSH) client, for secure access to remote machines
ii openssh-server 1:6.7p1-5+deb8u3amd64
secure shell (SSH) server, for secure access from remote machines
ii openssh-sftp-server1:6.7p1-5+deb8u3amd64
secure shell (SSH) sftp server module, for SFTP access from remote machines
ii python-paramiko1.15.1-1all
Make ssh v2 connections with Python (Python 2)
ii task-ssh-server3.31+deb8u1 all
SSH server
nick@RBMK-1000:~$
Re: ssh does not source /etc/bash.bashrc, but manual execution of /bin/bash does it under specific circumstances
Hello Chet and Eduardo, thank you very much for your replies. Everything is crystal clear now. Sorry for the 'wrong alarm' (: Best, Nick On 20/12/2016 20:24, Chet Ramey wrote: On 12/20/16 11:11 AM, Nick wrote: i came up with a weird behavior of ssh+bash on my Debian box (8.6). I created an alias in /etc/bash.bashrc file, which is sourced through /etc/profile. Everything worked fine, till i decided to remove the '. /etc/bash.bashrc' line from /etc/profile. When i` m connected via ssh the '/etc/bash.bashrc' is not sourced and the alias does not work as expected. But, when i execute bash from my shell, the '/etc/bash.bashrc' seems to be sourced and the alias is there (please find bellow a demo) ssh without a command is equivalent to slogin, which starts a login shell on the remote host. Login shells don't execute ~/.bashrc (and, if so configured, SYS_BASHRC), so there's usually a line to source it in one of the login shell startup files (/etc/profile in your case). That's why it's there, and that's why removing it had the effect you observed. Not sure if i miss something (f.x. bash is executed with different flags while being called from ssh versus a user), but as far as i understand, the same things should be (or not) sourced. Well, it's the difference between a login shell and a non-login interactive shell.
bash, echo or openssl bug?
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-pc-linux-gnu' -DC$ uname output: Linux buildserver 2.6.27-11-server #1 SMP Wed Apr 1 21:34:13 UTC 2009 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 3.2 Patch Level: 39 Release Status: release Description: i dont know if the bug is a bash bug or openssl or echo, but when i echo a string and pipe it to openssl, the output comes on the same line as the prompt instead of a new line. it makes the output hard to read because it is prepended to the prompt text, e.g. mySecretPasswordtcadmin@buildserver: ~$ Repeat-By: 1. run the following code in bash terminal: echo OHBjcWNLNGlQaVF5 | openssl base64 -d 2. the output in the bash terminal looks like this: mySecretPasswordtcadmin@buildserver: ~$ 3. the output SHOULD look like this: mySecretPassword tcadmin@buildserver: ~$
Re: bash, echo or openssl bug?
thanks eric and mike for your quick reply and suggestions =) 2012/1/3 Eric Blake > On 01/03/2012 06:48 AM, nick humphrey wrote: > > Description: > > i dont know if the bug is a bash bug or openssl or echo, but > when i > > echo a string and pipe it to openssl, the > > output comes on the same line as the prompt instead of a new line. > > None of the above. It's not a bug. Your encoded string does not have a > trailing newline, and your $PS1 settings don't inject a starting > newline, so the behavior is expected. If you want to guarantee a > trailing newline, then add one manually: > > > 1. run the following code in bash terminal: > > echo OHBjcWNLNGlQaVF5 | openssl base64 -d > > echo OHBjcWNLNGlQaVF5 | openssl base64 -d && echo > > or modify your PS1 to start with a newline request. > > -- > Eric Blake ebl...@redhat.com+1-919-301-3266 > Libvirt virtualization library http://libvirt.org > >
Re: Bash segmentation fault on startup/ssh
Hi Chet, I was able to solve the problem; I had accidentally set my bashrc file to source itself upon startup, which caused the segmentation fault. Changing the file fixed the problem as far as I can tell. Thanks for following up. Thanks, Nick On Mar 31, 2012, at 8:51 PM, Chet Ramey wrote: > On 3/30/12 3:42 PM, Nitz wrote: > >> Machine Type: i386-redhat-linux-gnu >> >> Bash Version: 4.1 >> Patch Level: 2 >> Release Status: release >> >> Description: >> >> I am getting a segmentation fault from bash when I try to SSH to a >> remote server (running RHEL 4.4.5-6). After providing my credentials, >> the SSH client spits back the "Last login: ..." information, and then >> just hangs. > > If you can reproduce the crash using gdb, gdb bash and run -x and look at > the command trace. > > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
documentation... readonly help is not accurate
Hello, Sorry if this has been reported earlier, but I can't find nothing related in the archives. $ help readonly | grep -- '-p' readonly: readonly [-aAf] [name[=value] ...] or readonly -p -pdisplay a list of all readonly variables and functions $ echo $BASH_VERSION 4.2.37(1)-release I think the description should say "or" instead of "and". I think it's the sorter way to clarify the behavior. This is, it will not print readonly functions unless called with -fp, and in such case, it will not print variables, so in my opinion, using "or" could be more accurate than "and". In the man page, it says... "If no name arguments are given, or if the -p option is supplied, a list of all readonly names is printed." but in practice it only prints variables (including arrays and associative arrays). The only thing it says about -f is "If the -f option is supplied, the functions corresponding to the names are so marked.". Maybe it could be better something like "If the -f option is supplied, restricts _name_ to functions" or something similar. On "help declare" uses in the descriptions "restrict action ..." and points to "NAME", while "help readonly" uses "refer to ..." (indexed array, associative, etc), maybe it needs a review for clarity and consistency. Also, for completion, maybe the "description" line of "help readonly" or "help -d readonly" (as well as for "help declare") could be updated from "variables" to "variables or functions". A lot of thanks. Best regards -- Iñigo Tejedor Arrondo
Re: documentation... readonly help is not accurate
On 4 March 2013 14:51, Chet Ramey wrote:
>
> This isn't accurate. Run the following script:
>
> foo()
> {
> echo foo
> }
> bar=quux
>
> readonly foo
> readonly bar
>
> readonly
>
> In addition to the built-in bash readonly variables, both bar and foo will
> be listed.
Maybe I'm wrong, but this is creating a variable "foo" which is empty.
After this, we can re-declare foo() and it works. For example foo() {
echo bar; }
But trying foo=1 fails (as we created a readonly variable).
Maybe this is more clear to explain what I was stating:
foo1 () { echo foo1; }
readonly -f foo1
foo2=1
readonly foo2
readonly -pf
readonly
Best regards
--
Iñigo Tejedor Arrondo
Re: Making "cmd< <(...)" useful (reliable)
Hello,
I can not help too much on the "bug" side, but I would like to give a
tip regarding the situation you describe.
Often I've the same caveats about how my code will be used in a future
without my control...
If you know for sure, what makes the code unreliable, in this example
the /proc subsystem status in the platform, then just check for it at
the beginning of the program, and cancel the execution gracefully.
Something like (just an example)...
[ -e /proc/vmstat ] || {
printf '%s\n' "ERROR: this program needs /proc" >&2
exit 1
}
That may not be the best or more elegant fix, but it will allow you to
relax about such unreliable behavior and go on.
Of course, there will be dragons... maybe in a future /proc/vmstat
disappears in the kernel changelog, or some new security feature makes
the issue appear again if the nested construct involves different
users, or... etc).
I agree regarding your request for reliability, but sometimes is not
easy at all, or you will need to support bash versions without the
fix...
I suspect this maybe related to the code in subst.c, but in 2 minutes
I did not see the exact portion bothering you. There are some comments
regarding nested process substitution, shell options, etc. No
references to /proc in that file.
Good luck !
On 30 June 2014 01:47, Linda Walsh wrote:
> Right now, I just noticed myself steering away from the "cmd< <(xx)"
> construct, in a normal runtime script where it would likely be safe, but
> in the back of my mind, a little voice says "but you don't know how this
> might be re-used", and if it gets re-used w/o proc mounted or present,
> then this will mysteriously break".
> Grrr..I get frustrated at not being able to use features that
> could greatly simplify code because they don't work "reliably"
> (i.e. I don't always know where a piece of code I write will end up
> being called from, since if I put it in a library, and it's called
> from another routine, which might be called from another...(etc...)
> kaboom.
>
> Is it possible to make that feature work, by default, w/o the unreliable
> part? I.e. in < <(xxx). Can't the part in (xxx) be forked into a child
> that has it's output fed into the parent?
>
> Right now we have (case 1):
> xxx|yyy|zzz for running "xxx" and "yyy" in children with "zzz" in a parent.
>
> So is there a reason for not doing similar for < <()?
>
> I.e. (case 2):
> zzz < <(yyy< <(xxx)) would very similar to the above. xxx runs
> as a child feeding its output into 'yyy' and 'yyy' would run as a child of
> zzz feeding its output into the input of 'zzz'.
> If it can be done w/ in the first case, _reliably_ (works w/o special
> file systems mounted), why not the 2nd case?
>
> Could someone point out what I am missing or why they think it wouldn't
> work?
>
> Thanks!
> 𝓛𝓲𝓷𝓭𝓪
>
>
--
Iñigo Tejedor Arrondo
mac boot error
my bug is not as much with bash as it is with apple. i was using my mac, until a point where it said please restart, i restarted and it booted back into bash, and has been doing so ever since. i dont know how to solve this, maybe you guys have a solution? ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
mac boot error
my bug is not as much with bash as it is with apple. i was using my mac, until a point where it said please restart, i restarted and it booted back into bash, and has been doing so ever since. i dont know how to solve this, maybe you guys have a solution? ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
hardwired DEBUGGER_START_FILE points to wrong location
Currently if the environmental variable is not set then
DEBUGGER_START_FILE defaults to this;
configure.in: DEBUGGER_START_FILE=
${ac_default_prefix}/lib/bashdb/bashdb-main.inc
However looking at the bashdb package Makefiles I note that
bashdb-main.inc will be found in $(datadir)/bashdb/, thus I think
DEBUGGER_START_FILE should default to that instead of
${ac_default_prefix}/lib/
Simply changing this to;
configure.in: DEBUGGER_START_FILE=${datadir}/bashdb/bashdb-main.inc
does not quite work as pathname.h ends up looking like this;
#define DEBUGGER_START_FILE "${prefix}/share/bashdb/bashdb-main.inc"
but I'm sure someone that understands autoconf/automake better can
correct this.
Thanks,
Nick
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: hardwired DEBUGGER_START_FILE points to wrong location
Nick Brown wrote:
> Currently if the environmental variable is not set then
> DEBUGGER_START_FILE defaults to this;
>
> configure.in: DEBUGGER_START_FILE=
> ${ac_default_prefix}/lib/bashdb/bashdb-main.inc
>
> However looking at the bashdb package Makefiles I note that
> bashdb-main.inc will be found in $(datadir)/bashdb/, thus I think
> DEBUGGER_START_FILE should default to that instead of
> ${ac_default_prefix}/lib/
>
> Simply changing this to;
>
> configure.in: DEBUGGER_START_FILE=${datadir}/bashdb/bashdb-main.inc
>
> does not quite work as pathname.h ends up looking like this;
>
> #define DEBUGGER_START_FILE "${prefix}/share/bashdb/bashdb-main.inc"
>
> but I'm sure someone that understands autoconf/automake better can
> correct this.
After reading section 4.7.2 "Installation Directory Variables" of the autoconf
manual (see below), realise this is because pathnames.h is generated at
configure time, but sould be generated at make time, by a makefile snippet.
Does anyone know how to do this for? (or I'm going to need to learn autotools
a lot more)
Cheers,
Nick
<--snip-->
Most of these variables have values that rely on prefix or exec_prefix. It is
deliberate that the directory output variables keep them unexpanded:
typically [EMAIL PROTECTED]@' will be replaced by `${prefix}/share', not
`/usr/local/share'.
This behavior is mandated by the GNU coding standards, so that when the user
runs:
`make'
she can still specify a different prefix from the one specified to
configure, in which case, if needed, the package shall hard code dependencies
corresponding to the make-specified prefix.
`make install'
she can specify a different installation location, in which case the
package must still depend on the location which was compiled in (i.e., never
recompile when `make install' is run). This is an extremely important
feature, as many people may decide to install all the files of a package
grouped together, and then install links from the final locations to there.
In order to support these features, it is essential that datadir remains being
defined as `${prefix}/share' to depend upon the current value of prefix.
A corollary is that you should not use these variables except in Makefiles.
For instance, instead of trying to evaluate datadir in `configure' and
hard-coding it in Makefiles using e.g.,
`AC_DEFINE_UNQUOTED(DATADIR, "$datadir")', you should add
`-DDATADIR="$(datadir)"' to your CPPFLAGS.
Similarly you should not rely on AC_OUTPUT_FILES to replace datadir and
friends in your shell scripts and other files, rather let make manage their
replacement. For instance Autoconf ships templates of its shell scripts
ending with `.in', and uses a Makefile snippet similar to:
edit = sed \
-e 's,@datadir\@,$(pkgdatadir),g' \
-e 's,@prefix\@,$(prefix),g'
autoconf: Makefile $(srcdir)/autoconf.in
rm -f autoconf autoconf.tmp
$(edit) $(srcdir)/autoconf.in >autoconf.tmp
chmod +x autoconf.tmp
mv autoconf.tmp autoconf
autoheader: Makefile $(srcdir)/autoheader.in
rm -f autoheader autoheader.tmp
$(edit) $(srcdir)/autoconf.in >autoheader.tmp
chmod +x autoheader.tmp
mv autoheader.tmp autoheader
Some details are noteworthy:
[EMAIL PROTECTED]@'
The backslash prevents configure from replacing [EMAIL PROTECTED]@' in the
sed
expression itself.
`$(pkgdatadir)'
Don't use [EMAIL PROTECTED]@'! Use the matching makefile variable instead.
`,'
Don't use `/' in the sed expression(s) since most likely the variables you
use, such as `$(pkgdatadir)', will contain some.
`Dependency on `Makefile''
Since edit uses values that depend on the configuration specific values
(prefix etc.) and not only on VERSION and so forth, the output depends on
`Makefile', not `configure.ac'.
`Separated dependencies and Single Suffix Rules'
You can't use them! The above snippet cannot be (portably) rewritten as:
autoconf autoheader: Makefile
.in:
rm -f $@ [EMAIL PROTECTED]
$(edit) $< >[EMAIL PROTECTED]
chmod +x [EMAIL PROTECTED]
mv [EMAIL PROTECTED] $@
See section 10.10 Limitations of Make, for details.
``$(srcdir)''
Be sure to specify the path to the sources, otherwise the package won't
support separated builds.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Bash crashes if you try to mapfile into an associative array
From: Nick Hobson To: bug-bash@gnu.org Subject: Bash crashes if you try to mapfile into an associative array Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=i686 -mtune=generic -O2 -pipe uname output: Linux localhost 2.6.31-ARCH #1 SMP PREEMPT Tue Oct 13 13:36:23 CEST 2009 i686 Intel(R) Celeron(R) CPU 550 @ 2.00GHz GenuineIntel GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 4.0 Patch Level: 33 Release Status: release Description: If you declare an array to be associative and then try to mapfile (or readarray) into it, Bash crashes. Repeat-By: declare -A x mapfile x
Custom word completion, word splitting, bad behavior
I witnessed the following in the word-splitting results passed to
custom completion functions. The word splitting performed goes haywire
when it sees the =' (equal, quote) or =" (equal double-quote)
character sequences. From this point on, practically no word-splitting
is performed. As these sequences are quite frequent (e.g foo
--bar="baz"), this forces the writer of custom completion functions to
do word-splitting himself, something doable, but certainly not trivial.
Take for example the following completion function written for
demonstration purposes:
_foo()
{
local cur prev
local DEBUG=/dev/pts/8
cur="${COMP_WORDS[COMP_CWORD]}"
prev="${COMP_WORDS[COMP_CWORD-1]}"
echo > $DEBUG
echo "" > $DEBUG
echo COMP_LINE $COMP_LINE > $DEBUG
echo COMP_CWORD $COMP_CWORD > $DEBUG
for w in "${COMP_WORDS[@]}"; do
echo -n "$w | " > $DEBUG
done
echo > $DEBUG
echo "$prev | $cur | " > $DEBUG
}
complete -F _foo foo
Once registered, then typing the following:
foo --bar=aa bb --baz="cc" dd ee ff gg
abd pressing [TAB], results in the following debugging output:
COMP_LINE foo --bar=aa bb --baz="cc" dd ee ff gg
COMP_CWORD 7
foo | --bar | = | aa | bb | --baz | =" | cc" dd ee ff gg |
=" | cc" dd ee ff gg |
As you can see after seeing the =" sequence the algorithm goes haywire
and stops splitting words.
The current value of COMP_WORDBREAKS is the default one:
$ echo $COMP_WORDBREAKS
"'@><=;|&(:
If I remove the double-quotes (") from COMP_WORDBREAKS then things get
back to normal! For the same command line I get the following very
reasonable splitting:
COMP_LINE foo --bar=aa bb --baz="cc" dd ee ff gg
COMP_CWORD 11
foo | --bar | = | aa | bb | --baz | = | "cc" | dd | ee | ff | gg |
ff | gg |
Obviously, though, I cannot change COMP_WORDBREAKS because this may
interfere with other completion functions.
So, I guess, my questions are:
1. Why are ' and " in the default COMP_WORDBREAKS
2. Why can't I pass wordbreaks specific to my function when I register
it with complete
3. Why does readline gets so messed up when it sees a =" and " is in
COMP_WORDBREAKS?
4. I'm currently writing a function to do word-spitting on COMP_LINE
myself. Since I don't want custom completion to be practically
disabled when the user passes an option value like --bar="baz" (totaly
reasonable and common), this seems the only solution (again, I can't
remove '" from COMP_WORDBREAKS for the reason mentioned above). But
this seems like an overkill.
Tested with:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='l
uname output: Linux coal 4.4.0-112-generic #135-Ubuntu SMP Fri Jan
19 11:48:36
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.4
Patch Level: 18
Release Status: release
Thanks in advance.
/npat
Please cc any answers to by personal address, as I'm not subscribed to
the list.
Re: Custom word completion, word splitting, bad behavior
Hi, Thank you for your reply. I'm not sure I understand everything, other than basically... "that's how readline does it". I don't suggest there's a bug in readline, but I don't understand, for example, why foo --bar "baz" aa bb is ok to be split like: foo | --bar | "baz" | aa | bb while foo --bar="baz" aa bb cannot be split like: foo | --bar | = | "baz" | aa | bb What would be so terrible with this, that isn't with the previous (with regard to being able to complete inside quotes, and such) In any case, splitting it like: foo | --bar | =" | baz" aa bb (the last part a single word) does not look reasonable to me (even if it may be convenient in some occasions I cannot think of). It looks like a mix-up between the roles of " as a quoting character and as a word break character. If I replace " with another word-break character (say :), the command is again split in a reasonable manner: foo | --bar | =: | baz | : | aa | bb Actually, " behaves like a word-break character only when it's a part of a sequence of other word-break characters (from what I can tell). As, for example, in: foo bar"baz foo | bar"baz(and not: foo | bar | " | baz) Anyway... confusing as it may be, it is as it is. I guess my question is: how would you suggest I handle completion for a command, when an option is given like --bar="baz"? After this point, my completion function stops getting split-up words and effectively keeps getting a prev being '="' and and a cur being the rest of the line. The only solution I can think of is to parse / break-up the line myself... If this is how it's usualy done, then ok Again, thanks for your answer. /npat P.S. It seems that I'm not the only one being bitten by this... I tried the bash-completion package (ships with many modern Linux distributions) and, if I'm not mistaken, even for simple commands like "ls", completion stops working when an option value is specified with =, and within quotes. Like: ls --block-size="150K" /[tab] (no completion) without the quotes, or without the equal, it works fine.
Re: Custom word completion, word splitting, bad behavior
On Wed, Feb 7, 2018 at 10:56 PM, Chet Ramey wrote:
> On 2/6/18 3:52 PM, Nick Patavalis wrote:
>>
>> In any case, splitting it like:
>>
>> foo | --bar | =" | baz" aa bb
>>
>> (the last part a single word) does not look reasonable to me (even if
>> it may be convenient in some occasions I cannot think of). It looks
>> like a mix-up between the roles of " as a quoting character and as a
>> word break character.
>
> That may, in fact, be unreasonable. I'll take a look.
>
> (It is not what I thought you were talking about as a problem: it seemed
> to me that the `="' part was where you were objecting.)
>
My worst problem is not the way '="' is split, but instead, how the rest
of the line is not (baz" aa bb).
To me, the best solution would seem to be *not* to treat "=" as a
separator (word-break character)---since you *don't* treat it as such
*anyway*, other than when it appears as part of a sequence of other
separators. That is, if this is ok
foo bar "baz" ---> foo | bar | "baz"
then, that's also ok:
foo bar="baz" ---> foo | bar | = | "baz"
>>
>> I guess my question is: how would you suggest I handle completion for
>> a command, when an option is given like --bar="baz"?
>
> Are you trying to complete the option word?
>
The option value ("baz"---which is not a big problem), but mostly
*everything past it* (the subsequent options and arguments).
/npat
Re: Custom word completion, word splitting, bad behavior
On Wed, Feb 7, 2018 at 11:12 PM, Chet Ramey wrote: > > You might try, as an intermediate step, removing `'' and `"' from > $COMP_WORDBREAKS and seeing how that works. I would be interested if it > affected readline's ability to complete within quoted strings. > I have tried this, and it works ok for me. It doesn't seem to change anything in the ability of readline to complete quoted strings / filenames, at least as far as I can tell. What worked with " in COMP_WORDBREAKS, seems to work without, what didn't, doesn't. In most cases the quotes are *not* separated from neither the previous, nor the following word, as in, for-example ls "/tmp/foo/a b" which is split by readline (with the *default* COMP_WORDBREAKS value, as well as without " in it), like: ls | "/tmp/foo/a b" so this is expected. Obviously, readline has no problem completing inside the quotes in both cases. On the other hand, readline seems not to be able to complete something like: ls /tm"p/foo/a b" (and I don't understand why), though this is true, regardless of whether " is in COMP_WORDBREAKS or not. I *both* cases, the command line is split (correctly) like: ls | /tm"p/foo/a b" so, probably, this is irrelevant with the discussion at hand. As I don't konw the internals of readline, I do not know in what corner case the presence of " in COMP_WORDBREAKS could have an effect. /npat
Re: Custom word completion, word splitting, bad behavior
On Mon, Feb 12, 2018 at 6:33 PM, Chet Ramey wrote: > > Because, as I said in my original reply, readline understands how to > complete inside quoted strings. If point is after the `b', for instance, > and you hit TAB, readline scans back to the open quote and passes > "p/foo/a b" to the completion function. > I see... Still the *line* is split correctly into two words (ls | tm"p/foo a b") regardless of the presence of '"' in COMP_WORDBREAKS. Then readline decides to complete the second word (tm"p/foo/ a b) in this manner (ignoring the part before the quotes). So this is not really pertinent to our original discussion... /npat
Re: tilde character not interpreted in variable set
On 3/2/18, 9:03 AM, "bug-bash on behalf of Koncz, Istvan (Extern)" wrote: 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-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/home/konczi.ext/apps/bin/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 -Wno- parentheses -Wno-format-security uname output: Linux OED-EX-DIG-L 4.13.0-36-generic #40-Ubuntu SMP Fri Feb 16 20:07:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.4 Patch Level: 18 Release Status: release Description: when i use ~/ for home folder it works in command line e.g. ls -la ~/.vimrc works, but when i add it to a variable e.g. foo="~/.vimrc" then ~/ will not be replaced to $HOME value like in command line, but i think it should be. ~ is a special character so must be escapped like \~ if i want the char, but without escape it should provide the home like in ls -la ~/ command. In my oppinion it is a bug. Current workaround is in shell script to use $HOME not ~/ but would be better if ~/ would be consistent and behave everywhere as same. Are you sure this is a bug? Consider the following: ubuntu:~ nchambers$ echo ~ /home/nchambers ubuntu:~ nchambers$ echo "~" ~ ubuntu:~ nchambers$ tmp=~ ubuntu:~ nchambers$ echo "$tmp" /home/nchambers ubuntu:~ nchambers$ tmp="~" ubuntu:~ nchambers$ echo "$tmp" ~ ubuntu:~ nchambers$ ~ is not an actual path, but rather a symbolic value expanded by the shell to whatever value is in HOME. Wrapping it in quotes prevents this expansion. Repeat-By: foo="~/.vimrc" echo $foo ~/.vimrc ls -la $foo ls: cannot access '~/.vimrc': No such file or directory ls -la ~/.vimrc -rw-r--r-- 1 konczi.ext users 19 Jan 2 12:49 /home/konczi.ext/.vimrc Fix: i would replace ~/ or ~ with $HOME value when there is a variable definition. If \~ is used, no replacement is needed because of the escaping. -- Mit freundlichen Grüßen/Kind regards Istvan Koncz Istvan Koncz OEDIV Digital Services (ODS) OEDIV Oetker Daten- und Informationsverarbeitung KG Bechterdisser Str. 10 33719 Bielefeld, Germany phone: +49 521 fax: +49 521 26050 445 mailto: istvan.ko...@oediv.de web: www.oediv.de Gesellschaftssitz: Bielefeld Registergericht: Amtsgericht Bielefeld HRA 13532 Der Umwelt zuliebe: E-Mails und Anhänge nur ausdrucken, wenn unbedingt nötig. Save paper - print e-mails and attachments only when absolutely necessary. _ Dieses E-Mail kann Informationen enthalten, die vertraulich sind und/oder dem Berufsgeheimnis unterfallen. Diese Information ist nur für den Gebrauch durch die in diesem E-Mail benannte Person oder Rechtseinheit bestimmt. Jede(r) unautorisierte Durchsicht, Gebrauch, Verwendung, Offenlegung oder Verbreitung ist verboten. Falls Sie nicht der beabsichtigte Empfänger sind, bitten wir Sie, den Absender durch Antwort E-Mail zu benachrichtigen und das empfangene E-Mail dauerhaft zu löschen sowie alle Kopien hiervon zu vernichten. Vielen Dank. Da über das Internet versandte E-Mails während des Übermittlungsprozesses leicht verfälscht und/oder unter fremden Namen erstellt werden können, übernehmen wir keine Verantwortung für den Inhalt der E-Mail oder der Anhänge und folglich kann der Inhalt des E-Mails kein rechtlich bindendes Angebot und keine rechtlich bindende Annahme eines Angebots begründen sofern nicht ausdrücklich schriftlich anders vereinbart. Diese E-Mail dient ausschließlich dem Informationsaustausch. Es gelten unsere Allgemeinen Geschäftsbedingungen. Wir unternehmen alle Anstrengungen, um unser Netzwerk von Viren freizuhalten. Dennoch sollten Sie dieses E-Mail und seine Anhänge auf Viren überprüfen, da wir keine Verantwortung für Computerviren übernehmen, die durch dieses Mail unbeabsichtigt übermittelt werden könnten. This e-mail may contain information that is confidential and/or privileged. This information is intended only for the use of the individual or entity named in this e-mail. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply e-mail and permanently d
Re: [BUG] ERR trap triggered twice when using 'command'
On 4/1/18, 5:54 AM, "bug-bash on behalf of Martijn Dekker" wrote: $ bash -c 'trap "echo WHOA" ERR; command false' WHOA WHOA Expected output: just one WHOA (as on *ksh, zsh) Thanks, - M. Please use the bashbug tool to submit the bug, so those that look at this can get some meaningful information about your environment (and at the very least, can know what version of bash you’re using).
Re: [BUG] ERR trap triggered twice when using 'command'
On 4/1/18, 5:54 AM, "bug-bash on behalf of Martijn Dekker" wrote: $ bash -c 'trap "echo WHOA" ERR; command false' WHOA WHOA Expected output: just one WHOA (as on *ksh, zsh) Thanks, - M. While you should still use the bashbug tool, I’m not sure if this is actually a bug. If you consider the following: NickChambers-iMac:~ Nick$ type command command is a shell builtin This means that when you execute `command false`, false is executed in a child subshell and command is executed in the current shell, and both return 1. Bash is able to see the exit status of false (since command is just a glorified C function in this case), so it activates the ERR trap. Then command exits, and bash once again activates the ERR trap (since command has the same exit status as the command it executed). If you execute `command false` in a subshell, bash will only see the exit status of command: NickChambers-iMac:~ Nick$ trap 'echo WHOA' ERR NickChambers-iMac:~ Nick$ ( command false ) WHOA NickChambers-iMac:~ Nick$
Re: Bash security issue
On 2014-09-25 15:08 -0700, Linda Walsh wrote: > Eric Blake wrote: > > Where I'm coming from is that in portable shell programming, you _can't_ > > assign a value to f()=... The fact that portable programs are now > > slammed with the notion that some values cannot be portably assigned > > to a variable... > --- > slammed? It's not like this is new... [...] > As other have said: > > «Geir Hauge wrote: Bash has had this feature since "forever"» > > «Pierre Gaston wrote: How many instance have you found since the > introduction of this feature more than 20 years ago?» Since I don't use bash it's not surprising that I've never noticed any problem. But I try to write scripts that are portable to bash, because I know that many people do use it. What I learned from this is that bog- standard assignments like this: foo=$1; export foo are not portable to bash, and may fail to work correctly depending on the user's input. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Re: Bash security issue
On 2014-09-26 08:51 -0600, Eric Blake wrote: > On 09/26/2014 08:45 AM, Nick Bowler wrote: > > On 2014-09-25 15:08 -0700, Linda Walsh wrote: > >> Eric Blake wrote: > >>> Where I'm coming from is that in portable shell programming, you _can't_ > >>> assign a value to f()=... The fact that portable programs are now > >>> slammed with the notion that some values cannot be portably assigned > >>> to a variable... > >> --- > >> slammed? It's not like this is new... > > [...] > >> As other have said: > >> > >> «Geir Hauge wrote: Bash has had this feature since "forever"» > >> > >> «Pierre Gaston wrote: How many instance have you found since the > >> introduction of this feature more than 20 years ago?» > > > > Since I don't use bash it's not surprising that I've never noticed any > > problem. > > > > But I try to write scripts that are portable to bash, because I know > > that many people do use it. What I learned from this is that bog- > > standard assignments like this: > > > >foo=$1; export foo > > > > are not portable to bash, and may fail to work correctly depending on > > the user's input. > > They are not portable to broken bash. But the argument in these threads > is that bash's implementation of function exports should be changed so > that _fixed_ bash will once again be POSIX compliant and let this > bog-standard assignment work regardless of contents. If Chet accepts > Florian's patch [1] to change function exports to use BASH_FUNC_foo()= > instead of foo= (which is what Red Hat is already using in their fixes > pushed today), then this POSIX compliance bug in broken bash will be > avoided. I agree. This sounds like a simple and effective solution. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Re: dead link
The problem is that the link under [promptvars] points to http://www.gnu.org/software/bash/manual/html_node/Controlling-the-Prompt.html#Controlling-the-Prompt, and not to the link mentioned above. *__* *Nick Stoughton* *Aether Things Inc * *San Francisco* +1 (510) 388 1413 On Sun, Mar 1, 2015 at 7:51 AM, Ryan Cunningham wrote: > Those two URLs are the same! > > -- > Ryan Cunningham > > > On Mar 1, 2015, at 1:28 AM, Jonathan Hadida < > jonathan.had...@univ.ox.ac.uk> wrote: > > > > Hi there > > > > There is a dead link in the online bash manual for shopt: > http://www.gnu.org/software/bash/manual/html_node/The-Shopt-Builtin.html > > [promptvars] "Controlling the Prompt" should point to > http://www.gnu.org/software/bash/manual/bashref.html#Controlling-the-Prompt > > It currently points to > http://www.gnu.org/software/bash/manual/bashref.html#Controlling-the-Prompt, > which yields a 404 > > > > Cheers, J > > > > >
Consequences of shell errors
I was surprised when the following script did NOT exit at the indicated line: set -e export X=$(false) # should not reach here echo did not exit Similarly, this fails in the same way: set -e X=$(false) export X # should not reach here echo did not exit while, conversely, this did exit as expected and exited on error: set -e X=$(false) # should not reach here export X echo did not exit The export utility is a special built-in, and according to POSIX XCU 2.8.1 "Consequences of Shell Errors", special built-ins should exit (with a diagnostic message) on both variable assignment error and expansion error. "An expansion error is one that occurs when the shell expansions defined in Section 2.6 are carried out" ... and section 2.6 includes command substitution. But every shell I tested behaves the same way (sh, bash, dash, ksh, mksh, yash and zsh), so I feel I must be missing something. Can someone explain why the first 2 examples do not exit on the error in the expansion? *__* *Nick Stoughton* *Aether Things Inc * *San Francisco* +1 (510) 388 1413
How to lock a terminal
Hi Everybody, I ma not sure if this is a bug, or if it is what causes it - if it isn't, then it is me being stupid. I was in a SSH session, and checking something inadvertently issued: > nano /var/log/messages | grep a (I was searching for something else than an 'a', but the above example shows the issue - about to use 'nano', but then forgot to change it to 'cat'). The terminal just sits there doing nothing - CTRL+C doesn't do anything; in a SSH session, the only option is to kill the terminal. On a local machine, you can use kill -9 from another terminal to get out of it. I don't know if this behaviour is expected or me being stupid, or something else going on. Regards, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
Re: How to lock a terminal
OK, everybody, Thanks for the replies. As I stated, it was me being stupid - why I didn't think of Ctrl+Z I don't know - I have only been using GNU/Linux for 14 years :) Mind you, it was late and I was rushing to stop my Raspberry Pi connecting to the AP rather than the range extender. Sorry for the noise. Nick On 16/02/16 10:19, Bob Proulx wrote: Nick Warne wrote: I was in a SSH session, and checking something inadvertently issued: > nano /var/log/messages | grep a (I was searching for something else than an 'a', but the above example shows the issue - about to use 'nano', but then forgot to change it to 'cat'). The terminal just sits there doing nothing - CTRL+C doesn't do anything; in a SSH session, the only option is to kill the terminal. On a local machine, you can use kill -9 from another terminal to get out of it. On a remote machine you can do the same. There really is no difference between local and remote here. You just use a second terminal for it. However this is the perfect case for job control. No need for a second terminal. Here is an example. Use Control-Z to stop the foreground job. rwp@havoc:~$ nano /var/log/messages | grep a ^Z [1]+ Stopped nano /var/log/messages | grep a rwp@havoc:~$ jobs [1]+ Stopped nano /var/log/messages | grep a rwp@havoc:~$ kill %1 Received SIGHUP or SIGTERM rwp@havoc:~$ jobs [1]+ Terminated nano /var/log/messages | grep a rwp@havoc:~$ jobs rwp@havoc:~$ Simply stop the process and then kill it using the same terminal. Bob P.S. The other suggestions to use Control-X to exit nano are also good too but job control is general for the entire class type of commands like this and I think good to know too. -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
[PATCH] typo in wait.def doc
Pretty trivial in the grand scheme of things, just wanted to report that the documentation for wait repeats "a". --- diff --git a/builtins/wait.def b/builtins/wait.def index 974f959b..46e764c5 100644 --- a/builtins/wait.def +++ b/builtins/wait.def @@ -28,7 +28,7 @@ Wait for job completion and return exit status. Waits for each process identified by an ID, which may be a process ID or a job specification, and reports its termination status. If ID is not given, waits for all currently active child processes, and the return -status is zero. If ID is a a job specification, waits for all processes +status is zero. If ID is a job specification, waits for all processes in that job's pipeline. If the -n option is supplied, waits for the next job to terminate and --- Nick Pongratz Systems Engineer Singlewire Software
