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 fo
> >(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
> log
> > 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
> >(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
> >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 t
> 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
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 leav
> 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 s
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 Fi
> > $ 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! Stupi
$ 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 PROTE
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 er
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
h
> > (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-. (digi
> 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 splittin
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':
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 pr
> "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-docume
Is this a bug, or just my misunderstanding about the scope of the "HERE"
operator (<<)?
Consider the following program:
echo THIS WORKS
cat
> 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 t
> 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
> > 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
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 n
24 matches
Mail list logo
