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
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
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)
(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
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
(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
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
My bash program basically does:
tail -f file outfile
killpid=$!
...
kill $killpid /dev/null 21
...
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
$ unalias fooee 21 /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
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:
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
(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
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':
Is this a bug, or just my misunderstanding about the scope of the HERE
operator ()?
Consider the following program:
echo THIS WORKS
cat GOOD | tr -d V= | grep '[0-9]*'
V=1234
abcd
GOOD
echo THIS DOES NOT WORK
foo=$(cat exp_test BAD | tr -d V= | grep '[0-9]*')
V=1234
abcd
BAD
When executed, it
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
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
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
17 matches
Mail list logo
