can't cd to directory with backslash
$ rpm -q bash bash-3.0-17 $ mkdir -p 'blah\' $ cd 'blah\' #lock up here -- Pádraig Brady - http://www.pixelbeat.org -- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: can't cd to directory with backslash
Chet Ramey wrote: [EMAIL PROTECTED] wrote: $ rpm -q bash bash-3.0-17 $ mkdir -p 'blah\' $ cd 'blah\' #lock up here There's no bug here. The cd builtin completes successfully, and the shell goes to read another line from the terminal. My guess is that the backslash at the end of $PWD is messing up an escape sequence you're sending to the terminal to write to the title bar or something similar. Well I thought that also, but reproduced it in gnome-terminal and xterm with PS1=$. The only common denominator was bash, as tcsh didn't show the problem? Pádraig. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: can't cd to directory with backslash
Chet Ramey wrote: Well I thought that also, but reproduced it in gnome-terminal and xterm with PS1=$. The only common denominator was bash, as tcsh didn't show the problem? Type `type -a cd' and see what it says. $ type -a cd cd is a shell builtin -- Pádraig Brady - http://www.pixelbeat.org -- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: can't cd to directory with backslash
Chet Ramey wrote: Chet Ramey wrote: Well I thought that also, but reproduced it in gnome-terminal and xterm with PS1=$. The only common denominator was bash, as tcsh didn't show the problem? Type `type -a cd' and see what it says. $ type -a cd cd is a shell builtin How about $PROMPT_COMMAND? I can't reproduce the problem when nothing tries to write $PWD to the title bar. Ok sorry. The following reliably hangs up the prompt on gnome-terminal and xterm: export PROMPT_COMMAND= echo -ne "\033]0;:blah\\\007" You *can* type reset though. Sorry for the noise. -- Pádraig Brady - http://www.pixelbeat.org -- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Builtin 'read' data not saved
Hello all, I'm at my wit's end. This script is not working: = #!/bin/bash B=none echo "2" | while read -r A; do B="$A" echo 1.B=$B done echo 2.B=$B == The output, from GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu), bash-4.2-2ubuntu2.1.deb, is this: 1.B=2 2.B=none I'm baffled; it's like the while loop is in a parallel universe. I tried 'export B=none' in line 2, with no effect. Help? -- f...@ch.pkts.ca
Re: Builtin 'read' data not saved
Here's some more oddities: =failing.sh: #!/bin/bash R="1|2" IFS='|' read -r A B <<< $R echo A=$A, B=$B Expected: "A=1, B=2" Actual: "A=1 2, B=" fail2.sh: #!/bin/bash R="1|2" while IFS='|' read -r A B; do echo 1:A=$A, B=$B done <<< $R echo 2:A=$A, B=$B Expected: 1:A=1, B=2 2:A=1, B=2 Actual: 1:A=1, B=2 2:A=, B= GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu) bash-4.2-2ubuntu2.1.deb Cheers! -- f...@ch.pkts.ca Thanks!
Why does this kill my box?
vi test.sh $0 = "test"; tail -f /var/log/messages chmod +x test.sh ../test.sh Seems to spawn loads of bash processes. 2.6.22-14-386 Linux GNU bash, version 3.2.25(1)-release (i486-pc-linux-gnu)
bash 3.2.51, ERR traps and subshells
Bash 4.1 does not set the ERR trap:
$ env -i HOME="$HOME" TERM="$TERM" bash3 <<\!
set -o errexit
set -o errtrace
TRIGGERED_ERR() { return $?; }
trap 'TRIGGERED_ERR' ERR
set -o xtrace
var=$(false) || true
echo $?
var=$(false || true) # only way of not triggering it...
echo $?
!
++ false # Subshell false
+++ TRIGGERED_ERR # Ignores outer "|| true"
+++ return 1
+ var=
+ true
+ echo 0
0 # But the entire command line does
# not set off errexit
++ false
++ true# Predictable second subshell...
+ var=
+ echo 0
0
Before I write a patch, is this bug documented? I could not find it in
the archives.
Is it a bug at all or is it expected behaviour?
According to the man page, it is not:
The ERR trap is not executed if the failed command is part of the command
list immediately following a while or until keyword, part of the test in an
if statement, part of a && or ⎪⎪ list, or if the command's return value is
being inverted via !
Andres P
Re: bash 3.2.51, ERR traps and subshells
On Tue, Jun 22, 2010 at 4:45 AM, Stefano Lattarini wrote: >> ++ false # Subshell false >> +++ TRIGGERED_ERR # Ignores outer "|| true" > No, it doesen't even see it; the script seen by the subshell consists > just of the string "false", so there is no `||' the subshell can see. > And this seems IMHO quite natural if you remember that the parent > shell and the subshell are run in two different proceses. > Thanks, makes sense. So this is a regression with bash 4? Because as I mentioned, the ERR trap does not trigger at any point in this example. Andres P
Re: bash 3.2.51, ERR traps and subshells
On Tue, Jun 22, 2010 at 2:21 PM, Chet Ramey wrote: > On 6/22/10 12:51 AM, Andres P wrote: >> Bash 4.1 does not set the ERR trap: > > It does, but remember that the ERR trap is only executed under the > circumstances that would cause the shell to exit when set -e is enabled. > To clarify, I meant that it does not trigger the trap, not that the actual `trap "" ERR' did not work. > One of the changes between bash-3.2 and bash-4.0 was to make command > substitution understand when it was being executed in a context where > the return value would be ignored, and to ignore any inherited setting > of -e and the ERR trap in those cases. This was part of the big change > in the behavior of set -e in response to the consensus of the Posix > working group, and more directly the result of a bug report. > >> The ERR trap is not executed if the failed command is part of the command >> list immediately following a while or until keyword, part of the test in >> an >> if statement, part of a && or ⎪⎪ list, or if the command's return value is >> being inverted via ! > > The exit status of the command substitution will ultimately be ignored > because it's part of an assignment statement on the LHS of a || list, so > the commands run in the command substitution inherit that state. > > Chet > Thanks, this behaviour seemed strange to me. Although eventually the outer `||' list taking precedence over contained subshells will seem natural in my use cases. It's more consistent. Andres P
Fwd: How not to inherit any environment variable from parent process?
Apparently this list doesn't set the Reply-To header, apologies. -- Forwarded message -- From: Andres P Date: Wed, Jun 23, 2010 at 12:10 AM Subject: Re: How not to inherit any environment variable from parent process? To: Peng Yu On Wed, Jun 23, 2010 at 12:02 AM, Peng Yu wrote: > I use bash --noprofile to start a bash session. Since this doesn't > source any profile files, I'd think that no environment variable > should be set. But I still see environment variables set. Are they > inherit from the parent session. Is there a way to start a bash > session without using parent environment variables? > env -i bash --noprofile Or more interestingly, env -i bash --rcfile /dev/null
Re: How to supply a string with space in it as parameter to a function?
On Wed, Jun 23, 2010 at 6:07 PM, Peng Yu wrote:
> #!/usr/bin/env bash
>
> function f {
> #for i in $*;
> for i in $@;
> do
> echo $i
> done
> }
>
You can also omit the variable intirely:
for i; do
echo "$i"
done
In that case, the for loop will iterate over "$@".
Andres P
Re: How to supply a string with space in it as parameter to a function?
On Wed, Jun 23, 2010 at 8:23 PM, Peng Yu wrote: > Why printf is better than echo? Is this because printf is more robust than > echo? Because if a string that is to be printed happens to be an echo flag, such as -n or -e, there's no straight forward way of escaping it such as with printf %s. Andres P
Mail Delivery (failure bug-bash@gnu.org)
Norman Virus Control a supprimé le message original qui contenait le virus [EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
loadable sleep exits immediately
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: /opt/project/buildroot/output/host/bin/x86_64-buildroot-linux-gnu-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-buildroot-linux-gnu'
-DCONF_VENDOR='buildroot' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -D_FORTIFY_SOURCE=1
-Wno-parentheses -Wno-format-security
uname output: Linux netbootbox 4.14.153 #6 SMP Tue Nov 12 14:20:37 CET 2019
x86_64 GNU/Linux
Machine Type: x86_64-buildroot-linux-gnu
Bash Version: 4.4
Patch Level: 23
Release Status: release
Description:
The loadable sleep function seems to exit almost immediately
in some specific cases.
Repeat-By:
The following minimal reproducable example illustrates the issue:
#!/bin/bash
enable -f /lib/bash/sleep sleep
aaa ()
{
type sleep
while true; do
echo -n "A"
dmesg >/dev/null &
sleep $1
done
}
while true; do
aaa 5 &
sleep 60
done
Workaround:
Use /bin/sleep
However this is unwatend for long running scripts, where it pollutes
the process list.
Re: Defect in manual section "Conditional Constructs" / case
- Original Message - From: "Andreas Schwab" To: Cc: Sent: Tuesday, August 24, 2021 3:19 PM Subject: Re: Defect in manual section "Conditional Constructs" / case On Aug 24 2021, dietmar_schind...@web.de wrote: In the section https://www.gnu.org/software/bash/manual/bash.html#Conditional-Constructs in the description of the "case" command there is no mention (as far as I can see, it doesn't follow from the documented expansions etc.) that a _pattern_ undergoes quote removal, but it does [see e. g. case aa in a""a) echo match;; esac]. (One might think it does self-evidently in the process of "Shell Expansions" performed on the command line, but this expansion series is not performed on the case command's _word_ and patterns - they for example don't undergo brace expansion -; for _word_, it is explicitly said: "The _word_ undergoes tilde expansion, parameter expansion, command substitution, arithmetic expansion, and quote removal …"; for _pattern_: "Each _pattern_ undergoes tilde expansion, parameter expansion, command substitution, and arithmetic expansion." - quote removal is missing.) That's because quote removal is _not_ performed. The quotes are significant for pattern matching, which needs to respect quoting. Doesn't the example I gave above show that quotes are removed? If they weren't, how could word aa with pattern a""a constitute a match? -- Dietmar
Surprising interaction between edit-and-execute-command, the cd builtin, and the prompt
Hi, Using bash 5.0.17 edit-and-execute-command I type in something like cd /tmp save and exit to execute. $PWD is properly updated but the prompt doesn't reflect the change (not until the next time it is printed). Piotr
Redirection bug in 2.05b
I found a redirection bug in bash 2.05b. I didn't see anything similar searching gnu.bash.bug, so I think this is new. Bash 2.05b fails with a bad file descriptor message when attempting certain complicated redirections. In the example below I am trying to tee stderr while also passing stderr to stdout. This seems to be fixed in 3.00, so I'm not sure how interested anyone will be. It's inconvenient for me because I have broken scripts after upgrading to RH Enterprise Linux 3, which comes with bash 2.05b. - Fritz ### OK in bash 2.03 on SPARC Solaris # tigger $ uname -a SunOS tigger 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra-30 tigger $ echo $BASH_VERSION 2.03.0(1)-release tigger $ ( ( ( echo OUT ; echo ERR >&2 ) 2>&1 >&3 ) | tee /tmp/x.err ) 3>&1 OUT ERR ### OK in bash 2.04 on SPARC Solaris # rabbit $ uname -a SunOS rabbit 5.8 Generic_108528-15 sun4u sparc SUNW,Ultra-30 rabbit $ echo $BASH_VERSION 2.04.0(1)-release rabbit $ ( ( ( echo OUT ; echo ERR >&2 ) 2>&1 >&3 ) | tee /tmp/x.err ) 3>&1 OUT ERR ### BUG in bash 2.05b on x86_64 Red Hat Enterprise Linux 3 # (also on 32-bit x86, not shown) # # Need to enclose in ( ) and add : command to get correct behavior # simba $ uname -a Linux simba 2.4.21-32.0.1.EL #1 SMP Tue May 17 17:52:26 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux simba $ echo $BASH_VERSION 2.05b.0(1)-release simba $ ( ( ( echo OUT ; echo ERR >&2 ) 2>&1 >&3 ) | tee /tmp/x.err ) 3>&1 bash: 3: Bad file descriptor simba $ ( ( ( ( echo OUT ; echo ERR >&2 ) 2>&1 >&3 ) | tee /tmp/x.err ) 3>&1 ) bash: 3: Bad file descriptor simba $ ( : ; ( ( ( echo OUT ; echo ERR >&2 ) 2>&1 >&3 ) | tee /tmp/x.err ) 3>&1 ) OUT ERR ### OK in bash 3.00 on x86 Mandriva 2005 Limited Edition # dotard $ uname -a Linux dotard 2.6.11-6mdk #1 Tue Mar 22 16:04:32 CET 2005 i686 Pentium III (Coppermine) unknown GNU/Linux dotard $ echo $BASH_VERSION 3.00.16(2)-release dotard $ ( ( ( echo OUT ; echo ERR >&2 ) 2>&1 >&3 ) | tee /tmp/x.err ) 3>&1 OUT ERR ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
feature request
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-$ uname output: Linux kafka 2.4.32 #1 SMP Tue Dec 27 21:33:51 CST 2005 i686 GNU/Linux Machine Type: i386-pc-linux-gnu Bash Version: 2.05b Patch Level: 0 Release Status: release Description: It would be very useful to have a shell option that displays the exit code of each command when it terminates. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: new features to GNU Bash
Hello, I suppose I have found a new feature to Bash. If user needs to rename a file and the file is in directory /home/user/a/b/c/d/e/file, user needs to write command mv /home/user/a/b/c/d/e/file /home/user/a/b/c/d/e/fileB. This command contains the directory written two times. so if Bash would remember directory, it would be possible to retrieve directory from memory the second time it is needed. That way user does not need to rewrite the same long directory again. there should be a key combination to retrieve the directory from memory to command line. I also have three other feature propositions. a) In Bash scripts (and more generally in any programming language), there could be a feature, which, when user presses F1 in place of a source code line, would tell in plain English what the source code line does. that would be useful for those who are learning new programming language and need to know what a source code does. also hard-to-find typos would be revealed this way. b) There could be file system level feature, which like lsattr tells more about files. This would tell file description, which could be very long, more than 256 characters. File description could be read e.g. by file command. c) file attributes could be increased to help classify huge file amounts in large disk partitions. that way finding files would be easier if find command would be told to search files with e.g. attribute z set. Z could be anything (e.g. script files, which user A has created between 1.1.2000 - 2.2.2002) and they could be created by user for any purpose. single letter file attribute name (like z) and file attribute description would be separate, so disk space would not be wasted. there could be a tool for reading what new file attributes exist and their description. I hope you forward these feature propositions to others. Regards, Mika M. --- Richard Stallman wrote [at Mon, 14 Jun 2010 03:13:48 -0400] : > a) if user is renaming a file in directory A and working directory is > different than A, (mv /path/file /path/renamed_file) and directory path contains many directories, We don't call that a "path" -- we call it a directory name. In GNU we use the term "path" only for a list of directories to be searched. It was hard for me to understand the feature you have in mind. I suggest you describe it in a more concrete way, and send the suggestions directly to bug-b...@gnu.org. * Tutustu tapahtumiin ja valokuviin kaikkialta Suomesta! www.suomi-neito.fi
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
