$ 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
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 backsl
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.or
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_CO
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-p
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
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)
ly 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
here 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
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.
>
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, Pe
hat case, the for loop will iterate over "$@".
Andres P
h printf %s.
Andres P
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
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-buildro
- 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#Conditi
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
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 t
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
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 wou
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
> > 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
> 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
> 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
Is this a bug, or just my misunderstanding about the scope of the "HERE"
operator (<<)?
Consider the following program:
echo THIS WORKS
cat
> "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
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
x27;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
> 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
> > (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
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
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
$ 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
> > $ 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
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
> 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
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
> 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
> >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
> >(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
> > 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)
> >(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
> 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
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
44 matches
Mail list logo
