announcing bashj
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='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-vEMnMR/bash-4.4.18=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux MMM 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.4 Patch Level: 19 Release Status: release Description: BASHJ - ANNOUNCE TO THE DEVELOPMENT TEAM OF BASH I am pleased to inform you about bashj - a bash 'mutant' with java support. This product opens numerous very interesting fields to bash developers. I invite you to visit: [1]http://fil.gonze.org/wikiPG/index.php/Project_bashj_:_a_bash_mutant_ with_java_support [2]http://fil.gonze.org/wikiPG/index.php/Bashj_programming_guide [3]https://sourceforge.net/projects/bashj/ I also strongly invite you to download, test and use bashj. And of course I would be happy to read your opinions, suggestions... [4]f...@gonze.org References 1. http://fil.gonze.org/wikiPG/index.php/Project_bashj_:_a_bash_mutant_with_java_support 2. http://fil.gonze.org/wikiPG/index.php/Bashj_programming_guide 3. https://sourceforge.net/projects/bashj/ 4. mailto:f...@gonze.org
show-all-if-ambiguous broken?
In my .inputrc I have: set print-completions-horizontally on set show-all-if-ambiguous on Despite of this, I have to type TWICE to get the completions listed. Is there a bug in the completion system, or do I miss yet another option? I'm using bash 2.05b (unfortunately, upgrading to 3.x is not an option). Ronald -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
RE: show-all-if-ambiguous broken?
> > In my .inputrc I have: > > > > set print-completions-horizontally on > > set show-all-if-ambiguous on > I cannot reproduce it. Do you use the programmable completion > package? I rarely use it (and can't check it right now). I don't know which completion package is installed (how can I find out?), but I guess that bash 2.05 is installed "right out of the box" of Red Hat Linux. Ronald ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
RE: show-all-if-ambiguous broken?
> 1. Are you sure your inputrc is being read? Yes, I had verified this in two ways: First I have changed some of the character bindings in my .inputrc, and then I have typed Ctrl-X Crtl-R on the shell prompt. The effect was that my character binding had changed, but the completion behaviour was still faulty. > 2. Does typing `bind "set show-all-if-ambiguous on"' at the > bash prompt > result in the option being successfully enabled? No, this does not output anything!!! > > 3. You can type `complete' at the bash prompt and see if you have any > completions defined. I don't think the completion > package turns off > any options, though. This doesn't display anything either. What can we conclude from this??? Ronald ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
RE: show-all-if-ambiguous broken?
> Did `echo $INPUTRC' display anything? THAT WAS IT! THAT WAS IT! THANK YOU SO MUCH! This variable was set (maybe by some malevolent sysadmin) to /etc/inputrc. It still puzzles me why bash, despite of this, was able to see the keybindings I had defined in *my* ~/.inputrc; maybe readline always tries to read ~/.inputrc first, and after this read $INPUTRC, which might result in settings being overwritten. After resetting INPUTRC and re-reading, completion works as expected. Thank you all for helping and caring! Ronald -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
HERE document mystery
Is this a bug, or just my misunderstanding about the scope of the "HERE" operator (<<)? Consider the following program: echo THIS WORKS cat
RE: HERE document mystery
> "Com MN PG P E B Consultant 3" > <[EMAIL PROTECTED]> wrote: > > echo THIS DOES NOT WORK > > foo=$(cat exp_test < > V=1234 > > abcd > > BAD > > 0. Since you passed a file name to cat, it will ignore stdin. > 1. Since the here-document belongs to the command in $(), the >here-document must also be entirely inside $(). Move the closing ) >after "BAD". > 2. [0-9]* matches every line, since * matches 0 or more occurrences. Thank you VERY much! I introduced stupidity #0 and #2, when I tried to turn my real application into a "simple example". But #1 was the explanation I was really looking for! I did not even know that a $(...) is allowed to span several lines. Ronald -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Keybinding "yank 0th arg", "delete backward argument"
I would find the following two functions useful in bash command line editing; is it possible to simulate them somehow with the current bash version, or would this have to be a new feature in a future version of bash? (1) yank 0th arg, similar to yank-last-arg, but copies the command part of the previous line into the current buffer. Example: The previous line was /usr/local/bin/perl myprog.pl then yank-0th-arg should insert /usr/local/bin/perl into the buffer. (2) delete-backward-argument, similar to delete-backward-word, but should delete everything to the left until the first white space. Ronald -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Backquote Mystery
While hunting a bug in my script, I stumbled over an effect involving
the usage of
backquote and grep, which completely puzzles me. To reproduce the
effect, execute
first the following four commands, which create a small directory tree
in your
working directory and set the bash variable 'e':
mkdir -p dirx/sub/f
cd dirx
touch x
e=$('ls' *)
Wenn you now do echo $e, you should get the following output:
x sub: f
And here comes the mystery part. Execute the following two commands:
echo g|grep "$e"
echo g|grep "x sub: f"
Could some kind soul explain to me, why the first grep matches?
BTW, BASH_VERSION is "2.05b.0(1)-release"
Ronald
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
RE: Backquote Mystery
> Try echo "$e". Then read about Word Splitting in the Bash manual. Good point. Since no word splitting occurs within "$e", it is expanded to a string containing newlines: $ echo $e # Expansion without quotes -> word splitting x sub: f $ echo "$e" # Expansion with quotes -> no word splitting x sub: f grep then matches the empty line. Indeed, one can reproduce this with a much simpler example: $ u=$(printf 'ab\n\ncd\n') $ echo xx|grep "$u" xx So we don't have a mystery here, but rather an undocumented feature of grep (or at least not documented in the man pages of *my* version of grep): If the pattern is a string containing newline characters, grep matches each of these lines in order to every line in the input file, until a match is found. Thank you for pointing me into the right direction. Ronald -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
RE: Keybinding "yank 0th arg", "delete backward argument"
> > (1) yank 0th arg, similar to yank-last-arg, but copies the > command part > > of the previous line > > into the current buffer. Example: The previous line was > > > > /usr/local/bin/perl myprog.pl > > > > then yank-0th-arg should insert /usr/local/bin/perl into the buffer. > > M-0 M-. (digit-argument yank-last-arg) > > > (2) delete-backward-argument, similar to delete-backward-word, but > > should delete everything > > to the left until the first white space. > > C-w (unix-word-rubout) Exactly what I was looking for Thank you very much! ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
How to enable 'realpath'
I don't see how to enable the 'realpath' builtin: $ enable realpath bash: enable: realpath: not a shell builtin I'm running bash 2.05b.0(1), so realpath should be a loadable builtin here, isn't it? Ronald ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
strange segmentation violation in connection with <<< redirection
With bash 2.05b (unfortunately I have no access to a more recent version) under Linux, there is a strange error, which can be demonstrated with the following script - let's call it "segv": #!/bin/bash --norc schodo="" fgrep -q <<<$schodo If this script is executed, I get the following error: segv: line 3: 23129 Segmentation fault fgrep -q <<< $schodo The segmentation fault occurs when running fgrep, but the reason seems not to be fgrep, but bash: For example, I do NOT get a SEGV when I do one of the following changes: (1) I run these commands in an interactive shell, I don't get a SEGV. (2) I replace line 3 by what should be equivalent fgrep -q <<<"" (3) When I initialize schodo with a non-null string, for example schodo=:: Is this a bug in bash? Is it still reproducible in version 3? Ronald -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
why doesn't this error message go to the bit bucket?
$ unalias fooee 2>&1 >/dev/null bash: unalias: fooee: not found Why is the error message displayed here? Because of the redirection, I had expected that any error message resulting from the unalias command would go to /dev/null Ronald -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
RE: why doesn't this error message go to the bit bucket?
> > $ unalias fooee 2>&1 >/dev/null > > bash: unalias: fooee: not found > > > > Why is the error message displayed here? > > Because you have redirected stderr (fd 2) to the channel connected to > stdout (fd 1) before stdout was redirected to a different channel (to > /dev/null). Of course! Stupid me How could I make such a beginner's mistake! Thank you for pointing this out. Ronald Fischer -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
How to suppress "Terminated..." message after kill
My bash program basically does: tail -f file >outfile & killpid=$! ... kill $killpid >/dev/null 2>&1 ... Still I get the message (PID) Terminated tail -f file >outfile at the end of my script. Is there a way to suppress this message? (bash 2.05b) Ronald -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
RE: How to suppress "Terminated..." message after kill
> Com MN PG P E B Consultant 3 wrote: > > (PID) Terminated tail -f file >outfile > > Is there a way to suppress this message? (bash 2.05b) > > Use: > set +m > Why is monitor set for your script? That would only be typical for > interactive shells but not typical for scripts. Good point, but I'm pretty sure that this is not related to monitor. Look at the following script (which I named monitest.sh): #!/usr/local/bin/bash --norc echo $- set +m touch foo tail -f foo >bar & pid=$! sleep 1 kill $pid sleep 1 echo finish When I execute it, I get the following output: hB monitest.sh: line 9: 3486 Terminatedtail -f foo >bar finish >From this we can see: (1) Monitor was not set (2) Even if it had been set, +m would have turned it off (3) Still, the Terminated message is printed. Strange, isn't it? Someone out there using bash 2.05, who could try the above script and see whether the same result appears? Ronald -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
logout from interactive subshell
Does someone know how to deal with the following situation? Very often I do the following pattern: (1) rlogin to a foreign host (2) Invoke a subshell (for example because I'm setting a Clearcase View) (3) Logout from the host Step (3) needs two steps: First I have to type 'exit' to leave the subshell, and then either 'exit' or 'logout' to leave the login shell. Is it possible to automate this in such a way that I have to type only one command, to leave all subshells (in this case, only 1, but in general, I might be several subshells deep) AND then logout? One idea would be to use ps, locate the process to the current subshell, crawling upwards via the PPIDs to find the PID of the login shell, and kill it. But this seems to be such an awkward solution, that I thought maybe there is an easier way to do it. (Note: This posting goes to the bash and to the zsh mailing list, because this problem might be solved differently in both shells, and I'm interested in both solutions - of course a solution working in bash AND zsh would be preferable). Ronald -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
RE: logout from interactive subshell
> How about
> function rlogin() {command rlogin "$@"; exit}
> ?
H I don't see how this could help me. Actually, your
solution would EXIT the shell I came from, after the login
has finished!! So I not only have to type all the "exit"s on
the remote host, I would even loose my current shell on the
local host.
Maybe to repeat what I would like to do:
A typical application would go like this:
rlogin foobar
DO SOME STUFF
cleartool setview myview # this creates a subshell
DO MORE STUFF
cleartool setview yourview # now I'm two subshells deep
DO STILL MORE STUFF
# Now I want to exit
exit
exit
logout
I would like to have a (interactive) command which does the final two
exits plus
a logout for me.
BTW, I could imagine a solution using 'expect', which does the login,
then hands
over the control to the user, and finally if the user is done, performs
the
exit and logout.
Ronald
--
Ronald Fischer (phone +49-89-63676431)
mailto:[EMAIL PROTECTED]
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
RE: logout from interactive subshell
> >rlogin foobar > >DO SOME STUFF > >cleartool setview myview # this creates a subshell > >DO MORE STUFF > >cleartool setview yourview # now I'm two subshells deep > >DO STILL MORE STUFF > ># Now I want to exit > >exit > >exit > >logout > > > > I would like to have a (interactive) command which does the > final two > > exits plus > > a logout for me. > > exec cleartool I gave "cleartool" just as an example. The point is not that I do not want the subshells to NOT be created. In contrary, I *want* to have the subshells (and they are not always created by setting a view, but sometimes simply by invoking "bash" or "zsh" respectively), because I often want to make changes in the environment, do something, and then undo the changes, i.e. go back to the previous state of the environment. But there *are* quite often cases that I am deep in a series of interactive subshells, and decide I do not want to back up one or two levels, but leave all of them and logout. So your solution doesn't solve the original problem either Ronald -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
RE: logout from interactive subshell
> >(1) rlogin to a foreign host > >(2) Invoke a subshell (for example because I'm setting a > Clearcase > > View) > > Is it a subshell or a second-level shell? (In the first case, $$ and > $PPID remain the same.) Could you kindly explain the difference? I thought it's always the same - a process (being the current shell, or cleartool, or whatever) is doing a fork, followed by an exec of the new shell. In the particular case of "cleartool setview", I don't know how it is done, but here is an example of the PIDs: $ echo $$ 25494 $ echo $PPID 25493 $ cleartool setview rofi_dft $ echo $$ 2965 $ echo $PPID 25494 So PPID changed (which I thought is very natural, since I have a new parent process now). The same effect appears if I invoke "zsh" instead of "cleartool", so we have what you call a "second-level shell". Now I wonder what exactly would be a "subshell" then > Each subshell can use a trap to be able > to kill its parent. But bash and zsh behave differently concerning > traps. I can't use traps here, because I know only at "exit time", whether I want to logout completely, or just go up one level. > Alternatively, the command that invokes the subshell could call > 'exit' after it has finished (you can write a wrapper, e.g. as a > shell function). Here again, I would need to decide at the time I'm calling the subshell, what to do at the exit-time so not useful for me either. Regards, Ronald -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
RE: logout from interactive subshell
> > I can't use traps here, because I know only at "exit time", whether
> > I want to logout completely, or just go up one level.
>
> $ call_and_exit() { "$@"; if test $? -eq 42; then exit; fi; }
> $ call_and_exit cleartool ...
> $ exit 42
This looks clever. Maybe one should use "exit 42" too in the definition
of call_and_exit
to propagate the exit up, but basically a nice idea. Maybe only
disadvantage that I have
to think before when calling the subshell (either by calling it via
call_and_exit, or
by setting up suitable aliases for cleartool, bash, zsh etc., to do this
automatically)
- I had hoped I cut do this with an intelligent alias which gets me out
of any deep
nesting of subshells without having done any preparation work before.
But your solution
is at least cleaner than the brute-force way of finding the login shell
via ps, and
then killing it.
Will give your idea a thought. Thanks a lot.
Ronald
--
Ronald Fischer (phone +49-89-63676431)
mailto:[EMAIL PROTECTED]
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
RE: logout from interactive subshell
> >(1) rlogin to a foreign host > >(2) Invoke a subshell (for example because I'm setting a > Clearcase > > View) > >(3) Logout from the host > > > > Step (3) needs two steps: First I have to type 'exit' to leave the > > subshell, and then either 'exit' or 'logout' to leave the > login shell. > > On step (2) you use > > exec bash > > instead of just bash. This does not work in the general case since I don't know at the time of invoking bash, whether I will eventually just go back one level or logout completely. Imagine the following situation: rlogin foo VAR=val1 exec bash VAR=val2 Now if at this point I would decide to not logout, but just go up one level (in order to have the old value of VAR restored), there is no way to do it - typing exit would log me out *unconditionally*. Ronald -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
RE: logout from interactive subshell
> What about in your login (.bash_profile, etc) exporting a > variable, say > ROOT_PID=$$ and having a command/function/alias 'kill -s SIGHUP > $ROOT_PID'? This is equivalent to killing the rlogin connection, but > should clean up nicely if all you have are shells. Excellent idea! Thank you for this suggestion. Ronald -- Ronald Fischer (phone +49-89-63676431) mailto:[EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Why is this executed inside a subshell?
Consider the following program:
#!/usr/local/bin/bash --norc
export VAR=A
function setvar
{
VAR=B
echo X
}
V=$(setvar)
echo $VAR
When I execute it, I get as result "A", not "B", as I had expected.
If setvar would be an external program, I would understand the result,
as this would have to be run in a subshell; but it is a shell function,
and shell functions are supposed to be evaluated in the context of the
current environment. But it seems that within a $(...), even shell
functions are executed in a child process. Is this supposed to work that
way?
Ronald, using bash 2.05b.
--
Ronald Fischer (phone +49-89-63676431)
mailto:[EMAIL PROTECTED]
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
