Bug on history control, don't erase no dups
Hello, I have the following lines on my login script, intended to make my history big enough for me, and not to waste space by keeping several copies of the same command again anda again: HISTCONTROL='ignoreboth:erasedups' HISTSIZE=4096 HISTFILESIZE=4096 To make sure it is working as that, I do (where "$" is shell prompt): $set | grep HIST This outputs: HISTCONTROL=ignoreboth:erasedups HISTFILE=/path/to/my/.bash_history HISTFILESIZE=4096 HISTSIZE=4096 Part of my history is, righ now: 522 cd /var/tmp/; touch z 523 cd /var/tmp/; touch z 524 ll 525 ssh zabu 526 ssh ximi 527 ls 528 ssh zabu 529 ssh ximi 530 gprolog 531 GLOBALZS=10 532 gprolog --q="[test]" 533 gprolog --q "[test]" 534 gprolog --q "[tp]" 535 ssh ximi As you see, there are several repeated lines. Many of them are commands I use constantly. I started with a clean history. But even if not, the duplicates should have been erased, as I understood from the manual page? I suspect that, if I am not making any stupid mistakes, is it because I use to keep several shells opened at once. I open and close them in a semi-chaotic fashion. Do you sugest anything, or is this really a bug? Also, you may give me some advice on how to reproduce the bug, if what I told isn't that usefull for finding the problem. Bashbug script didn't work for me. I think it couldn't find vim on the right place. I tried making a copy of the script and changing the path on the file (wich I thought to be trivial), but there is no "vim" written in there either, so I gave up. o:) Kindly, B
Bug on history control, don't erase no dups
Hello, I have the following lines on my login script, intended to make my history big enough for me, and not to waste space by keeping several copies of the same command again anda again: HISTCONTROL='ignoreboth:erasedups' HISTSIZE=4096 HISTFILESIZE=4096 To make sure it is working as that, I do (where "$" is shell prompt): $set | grep HIST This outputs: HISTCONTROL=ignoreboth:erasedups HISTFILE=/path/to/my/.bash_history HISTFILESIZE=4096 HISTSIZE=4096 Part of my history is, righ now: 522 cd /var/tmp/; touch z 523 cd /var/tmp/; touch z 524 ll 525 ssh zabu 526 ssh ximi 527 ls 528 ssh zabu 529 ssh ximi 530 gprolog 531 GLOBALZS=10 532 gprolog --q="[test]" 533 gprolog --q "[test]" 534 gprolog --q "[tp]" 535 ssh ximi As you see, there are several repeated lines. Many of them are commands I use constantly. I started with a clean history. But even if not, the duplicates should have been erased, as I understood from the manual page? I suspect that, if I am not making any stupid mistakes, is it because I use to keep several shells opened at once. I open and close them in a semi-chaotic fashion. Do you sugest anything, or is this really a bug? Also, you may give me some advice on how to reproduce the bug, if what I told isn't that usefull for finding the problem. Bashbug script didn't work for me. I think it couldn't find vim on the right place. I tried making a copy of the script and changing the path on the file (wich I thought to be trivial), but there is no "vim" written in there either, so I gave up. o:) Kindly, B
Re: Bug on history control, don't erase no dups
I am guessing here. Something with multiple instances of bash acessing the history. Are duplicates checked when a bash session is closed? I am making up and example with 2 instances, B1 and B2: - history of B1 and B2 initially the same: com a com b com c What happens if I make these actions: - B1, com a - B2, com a - close B1 - close B2 Another similar example, but starting with a history with duplicates (wich is my current problem): com a com b com a Would be handled corretly? I am in a real rush now. If you (or anyone) can't reproduce it with these ideas, I will try to make a real example. Ideas on how to do that quickly and effectivelly would be very appreciated! :) Yours truly, B Chet Ramey wrote: > B wrote: > >> HISTCONTROL=ignoreboth:erasedups >> HISTFILE=/path/to/my/.bash_history >> HISTFILESIZE=4096 >> HISTSIZE=4096 >> >> Part of my history is, righ now: >> >> 522 cd /var/tmp/; touch z >> 523 cd /var/tmp/; touch z >> 524 ll >> 525 ssh zabu >> 526 ssh ximi >> 527 ls >> 528 ssh zabu >> 529 ssh ximi >> 530 gprolog >> 531 GLOBALZS=10 >> 532 gprolog --q="[test]" >> 533 gprolog --q "[test]" >> 534 gprolog --q "[tp]" >> 535 ssh ximi >> >> As you see, there are several repeated lines. Many of them are >> commands I use >> constantly. I started with a clean history. But even if not, the >> duplicates >> should have been erased, as I understood from the manual page? > > I can't reproduce this behavior. It's possible that you can still get > duplicated lines if you are in the habit of using history -n or > history -r, but I can't duplicate it using straight command input from > the keyboard. > > Chet >
Re: Bug on history control, don't erase no dups
I am guessing here. Something with multiple instances of bash acessing the history. Are duplicates checked when a bash session is closed? I am making up and example with 2 instances, B1 and B2: - history of B1 and B2 initially the same: com a com b com c What happens if I make these actions: - B1, com a - B2, com a - close B1 - close B2 Another similar example, but starting with a history with duplicates (wich is my current problem): com a com b com a Would be handled corretly? I am in a real rush now. If you (or anyone) can't reproduce it with these ideas, I will try to make a real example. Ideas on how to do that quickly and effectivelly would be very appreciated! :) Yours truly, B Chet Ramey wrote: B wrote: HISTCONTROL=ignoreboth:erasedups HISTFILE=/path/to/my/.bash_history HISTFILESIZE=4096 HISTSIZE=4096 Part of my history is, righ now: 522 cd /var/tmp/; touch z 523 cd /var/tmp/; touch z 524 ll 525 ssh zabu 526 ssh ximi 527 ls 528 ssh zabu 529 ssh ximi 530 gprolog 531 GLOBALZS=10 532 gprolog --q="[test]" 533 gprolog --q "[test]" 534 gprolog --q "[tp]" 535 ssh ximi As you see, there are several repeated lines. Many of them are commands I use constantly. I started with a clean history. But even if not, the duplicates should have been erased, as I understood from the manual page? I can't reproduce this behavior. It's possible that you can still get duplicated lines if you are in the habit of using history -n or history -r, but I can't duplicate it using straight command input from the keyboard. Chet
Re: string substitution broken since 5.2
Le 03/11/2022 à 18:49, Andreas Schwab a écrit : shopt -u patsub_replacement OK thanks, I read the 5.2 release notes. I just regret that this option is enabled by default, it will break many scripts running since years. -- Thierry Bothorel OpenPGP_0x81BB850F60BA2BC2.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[X-snmp-devel] あなたのテポドン買 います
nkÌsð²¶mÅ·©H
http://perfect-oneday.com/6001/37dm/
[EMAIL PROTECTED]
ß¾ÅÍ èܹñB»ñÈÞBÍ{ÉsªåèAXgXÌ
ͯûðtiÈÇÅüµÄ¢Ü·B
ÅßÍ«ªjðU¢zeÖ¼s·é±Æª½¢ÌªÀÅ·B
½ß³êésðü·½ßÉAnkBÍAêñ¾j«ðlÂñ¢É³¹
©ªÌÓÌÜÜÉé±ÆðDÝÜ·B
µ©µAÅãÍÇobN©çÍ°µcJAj«©ç˳ê½tð
û¢ÁÏ¢ÉÙ¨£é±ÆÉÈèÜ·B
http://perfect-oneday.com/6009/3dm/
»ñÈnkÌsð¤Ü¢½LÅÇñÇñnko^ÒªÁµÄ
¢Ü·Bµ©µAj«ªÜ¾Ü¾«è¸A¥ñ»ñÈnkðüµÄ °Ä
¾³¢B
Ú×ͺL©çüÁľ³¢B
[EMAIL PROTECTED]@[EMAIL PROTECTED]
http://perfect-oneday.com/6002/15dm/
___
X-snmp-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/x-snmp-devel
Calling external programs in bash script
Hi, I need a help in calling external programs from shell script. For example a java class or methods and c functions from a shell script. Thanks in advance for your help ! - Ramprasad B __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: at which byte do two strings differ
On Tuesday 6 May 2008 07:53, Nathan Coulter wrote: > Looking for a simple ways to output the byte at which two strings differ. > Here is one: > > cmp <(echo "hello") <(echo "help") | cut -d' ' -f5 | tr -d , > > Any other suggestions? I can't see how this pertains to gnu.bash.bug, however try this: echo 'hello help' | sed 's/\([^ ]*\)[^ ]* \1.*/\1/' | wc -m (this exploits the fact that a newline is appended at the end, so wc sees an additional character, and gives the expected result). If the strings can have spaces in them, then use a different separator. -- D.
Re: finding the index at which two strings differ
On Tuesday 6 May 2008 21:29, Bob Proulx wrote:
> I can't think of any way to do this natively in bash
Well, there's a loop solution, but it's a bit awkward:
a=help; b=hello; i=0
while [ $i -le $((${#a}-1)) ] && [ $i -le $((${#b}-1)) ]; do
if [ "${a:${i}:1}" = "${b:${i}:1}" ]; then
i=$((i+1))
else
break
fi
done
echo $((i+1))
--
D.
Re: finding the index at which two strings differ
On Tuesday 6 May 2008 22:33, Dave B wrote:
> while [ $i -le $((${#a}-1)) ] && [ $i -le $((${#b}-1)) ]; do
while [ $i -lt ${#a} ] && [ $i -lt ${#b} ]; do
--
D.
Re: Bash messes up spaces in command line agruments.
On Tuesday 6 May 2008 16:20, Herrmann, Justin wrote:
> Description: When I try to pass strings inside double or single quotes
> as command line arguments to my Bash script, leading spaces, trailing
> spaces, and multiple grouped embedded spaces are removed from the
> string. This also prevents me from passing in only a space or spaces as
> arguments to my script.
>
> Repeat-By: Save this script as 'startup':
>
> #!/bin/bash
> echo $#
> for ((index = 0; index <= $#; index++))
> do
> echo "$index |$(eval echo \${$index})|"
> done
> exit 0
>
> then type: ./startup ' some words '
>
> the script will print out:
> 1
> 0 |./startup|
> 1 |some words|
This is what I get:
$ ./startup ' some words '
1
0 |./startup|
1 | some words |
# ' some words '
Note that a space is missing. Try using the simpler indirection notation:
$ cat startup
#!/bin/bash
echo $#
for ((index = 0; index <= $#; index++)); do
echo "$index |${!index}|"# Try using this
echo "$index |$(eval echo \${$index})|"
done
exit 0
$ ./startup ' some words '
1
0 |./startup|
0 |./startup|
1 |some words |
1 | some words |
# ' some words '
I'm not sure about why, using your method, only a single space is lost
(instead of all leading, trailing and all but one intra-words).
I'm using
$ bash --version
GNU bash, version 3.2.33(1)-release (i686-pc-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
--
D.
Re: Bash messes up spaces in command line agruments.
On Wednesday 7 May 2008 14:54, Dave B wrote:
> $ ./startup ' some words '
> 1
> 0 |./startup|
> 0 |./startup|
> 1 |some words |
> 1 | some words |
> # ' some words '
This should have been
$ ./startup ' some words '
1
0 |./startup|
0 |./startup|
1 | some words |
1 |some words |
# ' some words '
ie, ${!index} works fine, while eval loses a space.
--
D.
Re: unexpected behavior of 'read' builtin
On Saturday 24 May 2008 02:44, Juliano F. Ravasi wrote: > Description: > > I got bitten by two unexpected (and undocumented) behaviors of > the 'read' builtin. > > The first one is that it doesn't seem to handle word separators > equally, making distinction when spaces and non-space > separators are used to separate words. The man page introduces the concept of "IFS whitespace", which seems to include space and tab characters. "If IFS has a value other than the default, then sequences of the whitespace characters space and tab are ignored at the beginning and end of the word, as long as the whitespace character is in the value of IFS (an IFS whitespace character). Any character in IFS that is not IFS whitespace, along with any adjacent IFS whitespace characters, delimits a field. A sequence of IFS whitespace characters is also treated as a delimiter." So, if I read that correctly (which might not be true of course), when you assign $'\t' (an IFS whitespace character) to IFS, it seems you fall into the case where "a sequence of IFS whitespace characters is also treated as a delimiter". > The second one is that it chops leading and trailing whitespace > when you provide one variable for assignment, and not when you > use the default $REPLY. This /seems/ to be documented. From the man page, section about "read": "If no names are supplied, the line read is assigned to the variable REPLY". So, I guess "the line read" here really means "the whole line", including leading/trailing spaces. On the other hand, when even a single name is supplied, word splitting is performed, so the removal of blanks is expected as the result of that. -- D.
Re: [[ ... =~ ... ]] is broken when RHS is quoted
Alexis Huxley wrote: > Description: > [[ ... =~ ... ]] is broken when RHS is quoted AFAICT that seems to have changed from 3.2alpha. According to the changelog, from version 3.2alpha, "Quoting the string argument to the [[ command's =~ operator now forces string matching, as with the other pattern-matching operators". $ bash -c '[[ "^apple" =~ ^apple ]]; declare -p BASH_REMATCH' declare -ar BASH_REMATCH='()' $ bash -c '[[ "^apple" =~ "^apple" ]]; declare -p BASH_REMATCH' declare -ar BASH_REMATCH='([0]="^apple")' Spaces (and possibly other special chars) in the RHS should be escaped: $ bash -c '[[ "apple banana" =~ ^apple\ banana ]]; declare -p BASH_REMATCH' declare -ar BASH_REMATCH='([0]="apple banana")' $ bash -c '[[ "apple banana" =~ ^(apple)\ (banana) ]]; declare -p BASH_REMATCH' declare -ar BASH_REMATCH='([0]="apple banana" [1]="apple" [2]="banana")' $ bash --version GNU bash, version 3.2.33(1)-release (i686-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. -- D.
Re: [[ ... =~ ... ]] is broken when RHS is quoted
Alexis Huxley wrote:
> "Quote removal" means that, as usual, quotes do not form part of the
> arguments, they merely serve to delimit the arguments, I take it.
> "Words between [[ and ]] ... quote removal performed" means on *all*
> words between [[ and ]] I take it. Hmm ... No, that can't be right
> otherwise
>
> bash -c '[[ "apple" =~ "(apple)" ]]; echo ${BASH_REMATCH[1]}'
>
> would say apple. Hmmm ... while the CHANGES file indicates that I
> was wrong that bash is broken, I would say that bash is broken
> *w.r.t. the behaviour documented in its man page*. What do you think?
But bash *does* do quote removal, if you supply quoted arguments. If you do
bash -c '[[ "apple" =~ "(apple)" ]]; echo ${BASH_REMATCH[1]}'
then bash does quote removal and sees
apple =~ (apple)
Then, since the RHS was quoted, it performs string matching instead of re
matching. But before that it did do quote removal nonetheless.
--
D.
Re: Strange return codes of continue
Roman Rakus wrote: > This is realy strange. I have two examples > First: > > while [ 1 ]; do > while [ 1 ]; do > continue 0 > done > done > echo $? > > > Second: > > while [ 1 ]; do > while [ 1 ]; do > continue 0 > done > echo $? > done > echo $? > > In first case I have echoed 1. And I am expecting the same result in > second case, but I get 0. Can anyone help me and say where is the > difference? continue [n] Resume the next iteration of the enclosing for, while, until, or select loop. If n is specified, resume at the nth enclosing loop. n must be >= 1. If n is greater than the number of enclosing loops, the last enclosing loop (the ‘‘top-level’’ loop) is resumed. The return value is 0 unless the shell is not executing a loop when continue is executed. -- D.
Re: Regular expression match operation with character classes fails in bash 3.2
John E. Wulff wrote: > I have just updated from "openSUSE 10.2" to openSUSE 11.0" Linux. My > backup shell script > is now broken. I tracked the problen down to the latest version of > "bash". > > The relatively new binary operator =~ does not match a regular > expression which contains a > character class in square brackets: eg. $xp =~ "[0-9]10" > > The behaviour is the same on a 32 bit machine with openSUSE 11.0 and > GNU bash, version 3.2.39(1)-release (i586-suse-linux-gnu) > > All three script lines below match correctly on SuSE Linux 9.3 with > GNU bash, version 3.00.16(1)-release (i586-suse-linux) > > Unfortunately I no longer have access to the bash version which worked > correctly with openSUSE 10.2 > > My observation is the fault was introduced fairly recently. > > Repeat-By: > The following very simple regular expression matches: > xp=310; if [[ $xp =~ "310" ]]; then echo "$xp matched"; else echo "$xp > not matched"; fi > > This does not match in Bash Version 3.2 > xp=310; if [[ $xp =~ "[0-9]10" ]]; then echo "$xp matched"; else echo > "$xp not matched"; fi > > This does not match either (more like the line in my broken shell > script) > xp=310; if [[ $xp =~ "[0-9][0-9]*" ]]; then echo "$xp matched"; else > echo "$xp not matched"; fi That has been discussed some days ago, it's the expected behavior. See http://lists.gnu.org/archive/html/bug-bash/2008-06/msg00083.html -- D.
Re: How to create parameterized aliases in bashrc
Aman Jain wrote:
> Hi
>
> I would like to create an alias to show Nth line of a file.
>
> I tried something like
> alias shline='head -$1 $2 | tail -1' #$1 is the line number and $2
> is the filename
># Usage should be :
> $shline 5 file.txt
>
> But it isn't working..
You can't pass parameters to aliases.
> Can anyone suggest a better alternative
Use a function.
shline() { head -n $1 "$2" | tail -n 1; }
--
D.
Re: 'read' primitive
Bob Proulx wrote: > To get the entire line verbatim you would need to use the $REPLY > variable. Or also use IFS= read -r foo < bar -- D.
Re: Equivalent of ksh, zsh {N}<[WORD] ?
Pierre Gaston wrote:
>> > On Tue, Aug 26, 2008 at 5:41 AM, R. Bernstein <[EMAIL PROTECTED]> wrote:
>> > > Both zsh and ksh have a way to open a file or duplicate a file
>> > > descriptor and let the interpreter pick the descriptor saving the
>> > > newly-allocated file descriptor number in a variable. In particular:
>> > >
>> > > exec {fd}<&0
>> Perhaps you are thinking of the variation without braces?
>>
>
> well, I was thinking of the normal redirection syntax:
> exec 3<&0
>
> I doubt '{fd}<&0' is meaningfull anywhere.in ksh {fd} tries to
> run the command {fd} like in bash
> in zsh it tries to run the command "fd"
> What are you talking about???
I think he refers to the fact that, with ksh, you can do for instance
$ exec {fd}<&0
$ echo $fd
10
$ exec {fd1}<&0
$ echo $fd1
11
I didn't try on zsh, but with bash you get:
$ exec {fd}<&0
-bash: exec: {fd}: not found
--
D.
Re: Equivalent of ksh, zsh {N}<[WORD] ?
Pierre Gaston wrote:
>> I think he refers to the fact that, with ksh, you can do for instance
>>
>> $ exec {fd}<&0
>> $ echo $fd
>> 10
>> $ exec {fd1}<&0
>> $ echo $fd1
>> 11
>>
>> I didn't try on zsh, but with bash you get:
>>
>> $ exec {fd}<&0
>> -bash: exec: {fd}: not found
>>
> ah sorry I didn't know this syntax
>
> on which ksh version does this work?
I tried that on a RHEL 5 system with
$ ksh --version
version sh (AT&T Labs Research) 1993-12-28 r
Actually, I just tried zsh, and the version installed on that system (which
looks pretty old) does not support the exec {fd}<&0 either.
$ zsh --version
zsh 4.2.6 (i686-redhat-linux-gnu)
--
D.
Re: Maximum limit of pipes in a single command ?
Keshetti Mahesh wrote: > Hi all, > > Can anyone tell me what is the maximum limit of number of pipes > that can be opened through a single command ? > > e.g; # ||| .| For what is worth, on my system (bash 3.2.33(1)-release) I can have 3332 pipes before bash gives an error. I used this command: (printf 'echo a';for i in `seq 1 3332`;do printf '|cat';done;echo) | bash If I replace 3332 with , bash gives bash: line 1: syntax error near unexpected token `|' Curiously, with this command (printf 'echo a';for i in `seq 1 3330`;do printf '|(read a;echo $a)'; done;echo) | bash the limit is 3330. Ulimit tells me that the maximum number of user processes is 16381, so it seems unrelated to that. Why do you want to know? -- D.
Re: Formating variable with caracter and date.
Dolphin06 wrote: > Hello all, > > I would like to give a variable a value which have a format like this one: > <3 letters>-- > should be yymmdd. Date of the day by default. > How would i do this, i know the date command is date +"%y-%m-%d", but i dont > know the syntax for mixing letters date and digit into one variable. > Also i would like to give the user a chance to change this default value, by > letting him enter one, so i would like to know how can i check if the > entered value is in the correct format. First of all, this list if for reporting bash bugs, not for general help requests. For that purpose, there are other, more appropriate, places, like for example the Internet newsgroup comp.unix.shell. Then, regarding your request: To assign that string to the variable, assuming <3 letters> is "ABC", and is "5" (replace with your own values), you can do this: var=ABC-$(date +%y%m%d)-5 The part about checking depends on what you want to check exactly, which isn't clear from your description. -- D.
Re: $(grep anycommand anyfile) fail
BlackEnvil wrote: > Description: using ` ` or $() with command that use dirnames with spaces > fail. > > there are diferent dirnames with this problem, and different situations that > cause these errors, not only with ls and not only with grep. > > bye > > > Repeat-By: > > [blacken...@space_star ~]$ cd $HOME; mkdir hello\ -world/; touch test; echo > "ls hello\ -world/" > test; $(grep ls test); > ls: invalid line width: orld/ > [blacken...@space_star ~]$ There are actually two problems here. After the command substitution, the shell does word splitting, and the command it sees is this (spaced for readability): ls hello\ -world ^^ ^^ arg1 arg2 The -world part is interpreted as the option -w to ls, and "orld" as the argument to that option, which is an invalid line width. To fix that, use -- to mark the end of options. But even if you do that, you would still get an error because ls would see two filenames: "hello\" and "-world", neither of which exists. > [blacken...@space_star ~]$ cd $HOME; mkdir hello-\ world/; touch test; echo > "ls hello-\ world/" > test; $(grep ls test); > ls: cannot access hello-\: No such file or directory > world/: > [blacken...@space_star ~]$ Same as above: the shell does word splitting on the result of command substitution, and what it sees is the command (spaced for readability) ls hello-\ world ^^^ ^ arg1 arg2 since those files or directory do not exist, ls correctly produces an error. In both cases what you're seeing is not a bug, but just expected behavior. -- D.
Re: Howto set a Readline variable (not in the init file!)?
Andi Bachmann wrote: > Hello > > I'm looking for a way to set a Readline variable, but without editing > the init (~/.inputrc or /etc/inputrc) file. > > E.g., I'd like to have > >set show-all-if-ambiguous on > > The thing is that I have to login to some remote server with a login > that I share with other users and I don't want to impose my settings by > saving my options in a file. > > I tried > > bind set show-all-if-ambiguous on > > but this leads to a corrupted readline behaviour: I can't type anymore 's'. > > Reading the manual > (http://www.gnu.org/software/bash/manual/bashref.html#Bash-Builtins) it > says explicitly (for the Builtin command 'bind'): > >"Display current Readline (see Command Line Editing) key and > function bindings, bind a key sequence to a Readline function or > macro, or set a Readline variable." According to the man, you should pass the readline binding or variable as a single argument to bind (or at least that's what the example shown seems to imply), so: bind 'set show-all-if-ambiguous on' The above line seems to do the trick for me. -- D.
Re: No tilde expansion right after a quotation
Angel Tsankov wrote:
> Eric Blake wrote:
>> According to Angel Tsankov on 2/15/2009 3:02 PM:
>>> I tried CPATH="${CPATH}${CPATH:+:}"~usr1/blah/blah. (I quote
>>> expansions just to be on the safe side, though I think home
>>> directories may not contain spaces.)
>> There are some contexts, such as variable assignments, where double
>> quotes are not necessary.
>>
>> foo='a b'
>> bar=$foo
>>
>> is just as safe as
>>
>> bar="$foo"
>>
>> In fact, it is MORE portable to avoid double quotes in assignments,
>> if you are worried about writing scripts portable to more than just
>> bash. Of these two constructs:
>>
>> foo="`echo "a b"`"
>> bar=`echo "a b"`
>>
>> only the setting of bar is guaranteed to parse correctly in all
>> shells.
> Eric, thanks for youy replay. If double quotes are not that portable, then
> how am I suppose to assign the output from some command to a variable when
> the output contains a space?
Word splitting doesn't happen on assignments, so:
$ var=$(echo "foo bar baz")
$ echo "$var"
foo bar baz
--
D.
Re: IFS valid characters
Stephane CHAZELAS wrote:
> 2009-03-10, 15:43(-04), Chet Ramey:
>>> What are the valid charactes for the IFS variable? In particular, is '\0' a
>>> valid one?
>> Technically, yes, but in practice it's not useful. There are too many things
>> represented as C strings to make NUL work right.
> [...]
>
> And to answer the rest of the question. In bash, any character
> except NUL is allowed in $IFS.
>
> Some points that should be noted:
> - the SPC, TAB and NL characters are treated specially.
> - contrary to in the Bourne shell, pdksh or zsh, IFS is an
> internal field terminator, not separator ("a:b:" is split
> into "a" and "b", not "a" and "b" and "" which makes it
> inappropriate to split $PATH for instance) (in the Bourne
> shell, it splits into "a" and "b" as well but that's because
> empty elements are removed there)
It looks like an empty word is created when the separator is at the
beginning, but not when it's at the end (bash 3.2 and 4):
$ IFS=':'
$ v=":a:b"
$ arr=($v)
$ declare -p arr
declare -a arr='([0]="" [1]="a" [2]="b")'
$ v="a:b:"
$ arr=($v)
$ declare -p arr
declare -a arr='([0]="a" [1]="b")'
--
D.
Re: $\n doesn't get expanded between double-quotes
On Friday 03 July 2009, Richard Neill wrote: > > X=$'a\nb c' > > This is still a missing feature: how to embed newlines in double-quoted > bash string assignment: > > For example, if I want to write: > > EMAIL_BODY="Dear $NAME,$'\n\n'Here are the log-files for > $(date)$'\n\n'Regards,$'\n\n'$SENDER" > > then this doesn't work. There are ways around it, such as: > - building up the string in pieces or > - EMAIL_BODY=$(echo -e "$EMAIL_BODY") > > but it's really ugly to do. Maybe I'm missing something, but what's wrong with EMAIL_BODY="Dear $NAME, Here are the log files etc." ? -- D.
Re: Possible Feature Requests (unsource, exchange)
On Tuesday 07 July 2009, Christopher Roy Bratusek wrote:
> Hi all,
>
> what I'm currently missing are the following two things (I'm not 100%
> sure if they are not available):
>
> unsource: the opposite of source (while source is making functions
> publically available, unsource would remove them)
source does not make any function available. It just reads and executes the
contents of the sourced file in the current context. If that file happens to
contain functions, those functions will be defined and available (not to
children though, unless they're exported), but it's just a side effect.
To "remove" a function, you just unset it:
$ foo() { echo "function foo"; }
$ foo
function foo
$ unset foo
$ foo
bash: foo: command not found
> exchange: exchanges the value of two variables (x=2 y=a; exchange x y;
> x=a y=2 -- need to be exported, so $1 $2 inside a function/script don't
> help that much)
The traditional way to exchange values between two variable is to use a
temporary variable:
$ x=a
$ y=2
$ tmp=$x
$ x=$y
$ y=$tmp
$ echo "now x is $x, y is $y"
now x is 2, y is a
It's not clear to me what you mean by "$1 $2 inside a function/script don't
help".
> echo no-expand: if you do echo $@ ($@ is $x $y for example) echo will
> print the values of $x $y instead of simply $x and $y is there a way to
> achieve this?
Sure, just quote it (and not only here, btw):
$ foo() { echo "$@"; }
$ foo '$x' '$y'
$x $y
--
D.
Re: regarding 'time' builtin
On Friday 17 July 2009, Linda Walsh wrote: > where does the output from the 'time' command "go" > > I.e. if I wanted to pipe the output to a prog or file, how would I > go about doing it? Please see http://mywiki.wooledge.org/BashFAQ/032 -- D.
Re: 'time' redirection, and pipe redirections in general
On Saturday 25 July 2009, Linda Walsh wrote: > AFAIK, I'm still screwed if I want to create more than one > pipe for outputs -- either sending stderr to one pipe and stdout to > another, OR a way of even doing what "tee" does, but built into the > shell, so I could, using the building "tee", a file descriptor as an > output target. IIUC, This can be accomplished with process substitution: myprogram 1> >(command1) 2> >(command2) 3> >(command3) etc.etc. where command1 gets what myprogram writes to fd 1, command2 gets what myprogram writes to fd 2, etc.etc. But maybe I'm not understanding correctly what you're looking for. -- D.
Re: Bash script file naming problem?
On Saturday 25 July 2009, michael rice wrote: > Is there a problem with naming a bash script file "script"? I'm using > Fedora 11. "script" is most likely the name of a command installed on your system (on mine, it's /usr/bin/script). Try "man script" and see. So if you really want to call your script "script", but you have to either call it using its path (./bin/script in your example), or make sure that the shell finds it before the system command for example by modifying PATH. To be honest, I would just pick a different name for your script. -- D.
Re: Bug in array populating does not respect quotes
On Thursday 24 September 2009 16:38:12 David Martin wrote:
> Description:
> When populating an array from a string in a variable does not
> handle quotes.
>
> Repeat-By:
>
> ~$ declare -a samplearray
> ~$ samplearray=( x y 'z k')
> ~$ echo ${samplearray[2]}
> z k
> ~$ samplestring="x y 'z k'"
> ~$ samplearray=( $samplestring )
> ~$ echo ${samplearray[2]}
> 'z
Not a bug. This is expected behavior. To do what you want, use eval:
~$ samplestring="x y 'z k'"
~$ eval samplearray=( "$samplestring" )
~$ echo "${samplearray[2]}"
z k
--
D.
Re: Real easy questions. Please answer
On Friday 25 September 2009 05:24:04 eatsubway wrote:
> sry i have a stupid question.
>
> I have a variable and need to know how many items are in it.
>
> for example:
> variable="abc xyz foo"
> what program can i call to print out 3
>
> right now im doing this...
>
> Counter()
> {
> echo $#
> }
> Counter $IDs
> but that just seems stupid
Use an array, so you will even be able to store elements with spaces in them.
--
D.
Re: bash accepts script with incorrect syntax and goes into infinite loop
On Friday 09 October 2009, Pierre Gaston wrote: > > Repeat-By: > >printf '%s\n%s\n' foo bar | while read NAME; > >echo NAME=$NAME > >do > >echo blah > >done > > Not sure what is the incorrect syntax, and it seems normal that it goes > into an infinite loop since echo is always true. Well, it seems to me (and as stated in the bug report) that a "do" should follow the "while read NAME;". -- D.
Re: bash accepts script with incorrect syntax and goes into infinite loop
On Friday 09 October 2009, Pierre Gaston wrote: > > Well, it seems to me (and as stated in the bug report) that a "do" should > > follow the "while read NAME;". > > the while syntax is like this: > "while list; do list; done" > and the manual says "A sequence of one or more newlines may appear in a > list instead of a semicolon to delimit commands." > so you can have: > > while command > command > do > > (the ; in the definition is probably there to keep the definition on one > line, you can replace the ; in all the other definitions by a newline like: > if command > then > > This also works the same way in the other shells. For me it's not a bug. Uhm, on a more accurate reading you're probably right. The POSIX syntax for while is while compound-list-1 do compound-list-2 done And "read NAME; echo NAME=$NAME" is a compound-list. So I was deceived by the formatting, I think you are right. Thanks for correcting me. -- D.
Re[2]:Greeting !
Hallo. I think we had correspondence a long time ago if it was not you I am sorry. If it was I could not answer you because my Mozilla mail manager was down for a long time and I could not fix it only with my friend's help I got the emails address out for me ..:) I hope it was whom we were corresponded with you are still interested, as I am, though I realize much time has passed since then... I really don't know where to start Maybe you could tell me a little about yourself since I lost our early letters, your appearance,age , hobbies, and are you still in the search? If it was you I wrote to and you are interested to get to know me better, I have a profile at : http://qZT.girlspage.org/ Don't really know what else to say for now I hope this is the right address Let me know if you are interested, And I hope you won't run when you see my picture :-) Yourth faithfully Marinka B. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
UID|EUID variables lose their ro properties
Hi! Below is some odd stuff I recently noticed, looks to me as a bug, though it's better if smarter people than me look at it as well to confirm that. :) Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/root/git_repos/bash/out/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 -Wno-parentheses -Wno-format-security uname output: Linux test 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.4 Patch Level: 12 Release Status: release Description: Whenever UID|EUID are exported to the env of newly exec Bash instance said variables lose their ro properties. Here's example: #!/bin/bash if (( ! UID )) \ && (( ! EUID )) ; then printf 'I am root (%u)\n' "$UID" # at this point, you can change UID|EUID to whatever # you like UID=BANANA EUID=PEANUTS printf 'UID=%s\nEUID=%s\n' "$UID" "$EUID" exit else printf 'I am %u, not root\n' "$UID" fi export UID EUID exec bash -c "UID=0 EUID=0 $0" Here's example of an output: $ ./test I am 1000, not root I am root (0) UID=BANANA EUID=PEANUTS To my understanding, those variables should not be changed at any point, just like e.g. PPID (which is not affected by the above). Regards, Michal
Unexpected (?) segfault after unset LANG
Configuration Information:
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
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)
x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.3
Patch Level: 33
Release Status: release
Description:
On the system which doesn't provide any locale (other than default, POSIX
one), Bash is hit with a segfault after the following is executed (I fork
into another Bash instance so the error about the segfault is clearly
visible):
Repeat-By:
# bash
# echo ${LANG:-foobar}
foobar
# LANG=UTF-8
# printf '%s\n' $'\u013b'
Ļ
# printf '%s\n' $'\u013c'
ļ
# unset LANG
Segmentation fault (core dumped)
# type printf
printf is a shell builtin
Note that this happens either after call to printf or echo is made. Also,
if I call printf before LANG is set, segfault doesn't happen after the
above is performed:
# bash
# printf '%s\n' $'\u013b'
\u013B
# LANG=UTF-8
# printf '%s\n' $'\u013b'
\u013B # should that return a proper char at this point instead?
# unset LANG
# : # everything works just fine
Fix:
Creating /usr/lib/locale/{UTF-8,whatever_LANG_is_set_to}/LC* on the target
system seems to fix the issue, but still, the way how Bash reacts to LANG
being unset looks a bit buggy. Reproduced locally with the fresh build of
4.4.19(1)-release as well.
Re: Unexpected (?) segfault after unset LANG
Core was generated by `bash'. Program terminated with signal SIGSEGV, Segmentation fault. #0 __gconv_close (cd=0x0) at gconv_close.c:35 35gconv_close.c: No such file or directory. (gdb) bt #0 __gconv_close (cd=0x0) at gconv_close.c:35 #1 0x7fbf1e17a59f in iconv_close (cd=) at iconv_close.c:35 #2 0x004964d0 in u32reset () #3 0x0046de67 in ?? () #4 0x0043b403 in sv_locale () #5 0x0043e53d in makunbound () #6 0x00481d45 in unset_builtin () #7 0x004327aa in ?? () #8 0x004349d4 in ?? () #9 0x00435b1b in execute_command_internal () #10 0x0043737e in execute_command () #11 0x004213be in reader_loop () #12 0x0041fca5 in main () (gdb) 2018-02-09 16:21 GMT+01:00 Chet Ramey : > On 2/9/18 9:55 AM, mike b wrote: > > > Bash Version: 4.3 > > Patch Level: 33 > > Release Status: release > > > > Description: > > On the system which doesn't provide any locale (other than default, POSIX > > one), Bash is hit with a segfault after the following is executed (I fork > > into another Bash instance so the error about the segfault is clearly > > visible): > > Stack traceback? The common element in all of these appears to be $'...'. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >
Re: Unexpected (?) segfault after unset LANG
Indeed, with build from devel it doesn't segfault anymore. Just out of pure
curiosity, which commit introduced a fix for that? Aaand, there's one more
thing that puzzles me a bit:
# echo $BASH_VERSION
5.0.12(1)-alpha
# echo ${LANG:-bleh}
bleh
# LANG=UTF-8
# printf '%s\n' $'\u013b'
Ļ
# unset LANG
# : # \o/ no segfaults
# printf '%s\n' $'\u013b'
\u013B
# LANG=UTF-8
# printf '%s\n' $'\u013b'
\u013B # why it returns just the code?
bash-5.0#
When LANG is set to UTF-8, printf returns actual character which coresponds
to given code after first call, however, after LANG is toggled, printf
keeps returning just the code. I guess my question here is: why that
happens? I mean, I would expect it to decode it whenever LANG is set back
to UTF-8 in this case. Am I missing something here?
2018-02-09 17:29 GMT+01:00 Chet Ramey :
> On 2/9/18 11:21 AM, mike b wrote:
> > Core was generated by `bash'.
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > #0 __gconv_close (cd=0x0) at gconv_close.c:35
> > 35gconv_close.c: No such file or directory.
> > (gdb) bt
> > #0 __gconv_close (cd=0x0) at gconv_close.c:35
> > #1 0x7fbf1e17a59f in iconv_close (cd=) at
> iconv_close.c:35
> > #2 0x004964d0 in u32reset ()
> > #3 0x0046de67 in ?? ()
> > #4 0x0043b403 in sv_locale ()
> > #5 0x0043e53d in makunbound ()
> > #6 0x00481d45 in unset_builtin ()
> > #7 0x004327aa in ?? ()
> > #8 0x004349d4 in ?? ()
> > #9 0x00435b1b in execute_command_internal ()
> > #10 0x0043737e in execute_command ()
> > #11 0x004213be in reader_loop ()
> > #12 0x0041fca5 in main ()
> > (gdb)
>
> Thanks. I'm pretty sure this is the problem I fixed last November. The fix
> is in the devel branch if you want to try that.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
>
Reading from a file by using its FD returns its contents only once
Configuration Information:
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-7fckc0/bash-4.4=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall -no-pie
-Wno-parentheses -Wno-format-security
uname output: Linux debian9 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2
(2018-10-27) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.4
Patch Level: 12
Release Status: release
I am not quite sure if this is a bug, but here's what I find as a bit odd
behavior:
# modprobe zram num_devices=0
# exec {add}./t
# exec 10<./t
# read -r <&10
# echo $REPLY
bla
# read -r <&10
# echo $REPLY
#
Playing with something like:
# zram=/sys/class/zram/control/hot_add
# c=0; while ((++c <= 3)); do read -r; echo "${REPLY:-NULL}"; done <"$zram"
0
NULL
NULL
#
also gets same results. In contrast to:
# c=0; while (( ++c <= 3 )); do read -r; echo "out: ${REPLY:-NULL}"; done
foo
out: foo
foo
out: foo
foo
out: foo
#
which keeps reading from default stdin (terminal in this case) without any
hiccups (as expected).
So, considering all the above, any hints on why subsequent reads in these
scenarios don't get any data from a file would be really appreciated. :)
Same behavior is seen in 4.3.30 and 5.0 versions.
Re: Reading from a file by using its FD returns its contents only once
That's a good point, I haven't thought about it like this. I always thought
that each read always starts at the beginning of the file given fd points
at. So the fact that it changes offset is a bit surprising:
# echo word >t
# exec {in}
napisał(a):
> On Mon, Dec 31, 2018 at 2:37 AM mike b wrote:
>
> [...]
>
> > The above is just an example. Doing reads on any other regular file like
> > this yields same behavior:
> > # echo bla >./t
> > # exec 10<./t
> > # read -r <&10
> > # echo $REPLY
> > bla
> > # read -r <&10
> > # echo $REPLY
>
> That's correct behavior because the second `read -r' already hits an
> EOF, isn't that?
>
> --
> Best regards,
> Tadeus
>
Re: Reading from a file by using its FD returns its contents only once
I have the full picture now. Thank you all for your feedback!
\w, $PWD and pwd builtin return "//" instead of '/'
Upon changing directory, with "//" passed as an argument, the trailing '/'
is still displayed when cwd is looked up by Bash:
bash-5.0# cd //
bash-5.0# pwd
//
bash-5.0# echo $PWD
//
bash-5.0# PS1=${PS1/\$/\w\\$}
bash-5.0//# # \w -> "//"
bash-5.0//# /bin/pwd # <- coreutils implementation
/
bash-5.0//#
This seems to happen only when number of '/' char == 2, anything > 2 is
properly displayed as single '/' char.
Same is observed in 4.4.12.
Re: \w, $PWD and pwd builtin return "//" instead of '/'
Ah, something was telling me that this could not have been missed, but after checking behavior on couple of different shells (csh, ksh, tcsh) I was convinced that it's not a proper behavior. Though now I see that, e.g., dash does the same thing. Note to myself: always check what POSIX has to say. Or at least remember to run through the FAQ. :) Anyways, thanks for your feedback! niedz., 13 sty 2019 o 02:43 Chet Ramey napisał(a): > On 1/12/19 7:52 PM, mike b wrote: > > Upon changing directory, with "//" passed as an argument, the trailing > '/' > > is still displayed when cwd is looked up by Bash: > > > > bash-5.0# cd // > > bash-5.0# pwd > > // > > bash-5.0# echo $PWD > > // > > Bash FAQ, question E10. That should tell you how long this question has > been asked. :-) > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >
Re: read builtin is not honoring -t argument
I'm very sorry; I believe I may have wasted your time. After further testing, I can only reproduce this using xfce4-terminal (0.6.2) in Fedora 19. Read works fine in gnome-terminal and on tty's, so I hereby respectfully retract my report. Thank you for the work you guys do! Just to show I'm not (completely) insane, though: [todd@tibs6 ~]$ echo $0 bash [todd@tibs6 ~]$ type -a read read is a shell builtin read is /usr/bin/read read is /bin/read [todd@tibs6 ~]$ time timeout -s 9 5s read -t 1 Killed real0m5.001s user0m0.000s sys0m0.000s [todd@tibs6 ~]$ time read -t 1 asdf real0m7.904s user0m0.000s sys0m0.000s --- On Thu, Dec 12, 2013 at 7:49 AM, Geir Hauge wrote: > 2013/12/11 > >> Description: >> read builtin is not honoring -t argument >> >> Repeat-By: >> Just run 'read -t1' and note that the behavior seems not >> different from simply running 'read' without arguments. >> > > What does ''type read'' say? perhaps you have a function or alias by that > name. I can't reproduce it either. > > -- > Geir Hauge >
Re: Parameter Substitution Causing Memory Leak
These bugs result in gradual slowdown of indefinitely-running scripts which
rely on parameter substitution (rather than forking sed or awk) for speed
and efficiency. Forgive me if I used the wrong terminology, but whether
these bugs are considered honest-to-goodness "memory leaks" by valgrind
seems unimportant.
Are you saying these bugs have been fixed, and that they no longer exist in
bash 4.3?
On Tue, Jan 7, 2014 at 11:12 AM, Chet Ramey wrote:
> On 1/7/14, 2:27 AM, toddbst...@gmail.com wrote:
>
> > Repeat-By:
> > These can all be demonstrated by running a script consisting of an
> infinite loop which repeatedly executes any command utilizing any of the
> above examples. Like this:
> >
> > #!/bin/bash
> >
> > while :; do
> > echo ${variable/pattern}
> > done
> >
> > The resident memory size will continually grow. This occurs on
> both CentOS 6.5 (bash 4.1.2) and Fedora 20 (bash 4.2.45).
>
> Have you run any of these through valgrind? I ran a few, and it did not
> report any leaks, at least on bash-4.3-rc1. The increase in memory size is
> probably from malloc getting memory from the kernel but not releasing it
> back to the kernel after bash calls free (giving memory back to the kernel
> is harder than you think).
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRUc...@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>
#! /bin/sh bash problem
From: jbb To: bug-bash@gnu.org Subject: gnu software "configure" error Configuration Information [Automatically generated, do not change]: Machine: i586 OS: linux-gnu Compiler: gcc -I/usr/src/packages/BUILD/bash-3.2 -L/usr/src/packages/BUILD/bash-3.2/../readline-5.2 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-suse-linux-gnu' -DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -march=i586 -mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -g -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -pipe -g -fPIE -fprofile-use uname output: Linux pinball 2.6.22.17-0.1-default #1 SMP 2008/02/10 20:01:04 UTC i686 i686 i386 GNU/Linux Machine Type: i586-suse-linux-gnu Bash Version: 3.2 Patch Level: 25 Release Status: release Description: Attempting to run 'configure', or any shell script with #! /bin/sh, results in the error message: "bash: ./configure: /usr/bin/bash: bad interpreter: Permission denied" Repeat-By: attempting to configure source for compiling. So far, any UNIX and Linux packages act the same; the above error. Fix: attempting to revert bash versions is not working; the older program will not download from openSuSE update sites. Shalom, John B. Brown. [EMAIL PROTECTED] 358 High Street, Buffalo, Wyoming 82834 "Freedom is not worth having if it does not include the freedom to make mistakes" Mahatma Gandhi "It is useless to attempt to reason a man out of what he was never reasoned into." Jonathan Swift "A man who does not know the truth is just an idiot but a man who knows the truth and calls it a lie is a crook." Bertolt Brecht "If any question why we died, tell them, because our fathers lied." Rudyard Kipling
Re: #! /bin/sh bash problem
Dear Bob,
Thank you for that reminder of my mortality.
Bob Proulx wrote:
John B. Brown wrote:
Description: Attempting to run 'configure', or any shell
script with #! /bin/sh, results in the error message:
"bash: ./configure: /usr/bin/bash: bad interpreter:
Permission denied"
I suspect that the permissions on /usr/bin/bash are preventing you
from running it. What does this following say?
ls -ld /usr/bin/bash
Also, /usr/bin/bash is not a normal location for bash. Normally bash
would reside in /bin/bash . Perhaps you also have one there?
ls -ld /bin/bash /usr/local/bin/bash
Bob
[EMAIL PROTECTED]:~
(23):% ls -ld /usr/bin/bash /bin/bash /usr/local/bash
/bin/ls: cannot access /usr/local/bash: No such file or
directory
-rwsrwsr-x 1 root root 604040 2007-09-21 16:16 /bin/bash*
-rwxr-xr-x 1 root root 2037410 2008-01-30 05:35 /usr/bin/bash*
[EMAIL PROTECTED]:~
(24):% /usr/bin/bash --version
GNU bash, version 3.1.0(1)-release (i686-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
[EMAIL PROTECTED]:~
(25):% /bin/bash --version
GNU bash, version 3.2.25(1)-release (i586-suse-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
[EMAIL PROTECTED]:~
Argh! I guess I get to REMOVE the bash I installed in
error in that piece of junk location.
So much for compiling by myself.
I must remember to set the proper --prefix in the configure
process; dueling bashes just doesn't make it.
Shalom,
John B. Brown.
[EMAIL PROTECTED]
358 High Street,
Buffalo, Wyoming
82834
"Freedom is not worth having if it does not include
the freedom to make mistakes" Mahatma Gandhi
"It is useless to attempt to reason a man out of
what he was never reasoned into." Jonathan Swift
"A man who does not know the truth is just an idiot but
a man who knows the truth and calls it a lie is a crook."
Bertolt Brecht
"If any question why we died,
tell them, because our fathers lied." Rudyard Kipling
Re: #! /bin/sh bash problem
Dear Bob, Thank you for your answers. Bob Proulx wrote: John B. Brown wrote: Thank you for that reminder of my mortality. :-) Bob Proulx wrote: Also, /usr/bin/bash is not a normal location for bash. Normally bash would reside in /bin/bash . Perhaps you also have one there? ls -ld /bin/bash /usr/local/bin/bash I suggested looking at /usr/local/bin/bash since that is another typical location. (23):% ls -ld /usr/bin/bash /bin/bash /usr/local/bash /bin/ls: cannot access /usr/local/bash: No such file or directory It is probably not an issue here but you looked at /usr/local/bash instead of where I suggested. It didn't exist. I doubt the /usr/local/bin/bash exists either. But I wanted to note that these were different paths. Actually, nothing exists in /usr/local/bin except space. Personally, the alternative to growing old and senile is not acceptable. -rwsrwsr-x 1 root root 604040 2007-09-21 16:16 /bin/bash* How did that happen? Fix that immediately, if not sooner. chmod a=rx,u+w /bin/bash Then also go check other files in your bin directory to make sure you didn't have an errant command set them all. That setuid/setgid to root was an interim stop-gap prior to asking for help; it is not usual. -rwxr-xr-x 1 root root 2037410 2008-01-30 05:35 /usr/bin/bash* That looks okay. But it doesn't match your previous error message. I assume you were continuing to make changes after your last message because this one shouldn't have given a permission denied one. I expected to see that this wasn't executable at all. Argh! I guess I get to REMOVE the bash I installed in error in that piece of junk location. So much for compiling by myself. I must remember to set the proper --prefix in the configure process; dueling bashes just doesn't make it. Careful when compiling and upgrading systems in place. A breakage can break your entire system to the point that you might not be able to use it to fix itself. Make sure you have a rescue process available. Bob I have rm'd all the symlinks to /bin/bash. I have remade all of them, including a symlink to /usr/bin/bash. If that doesn't finally fix this mess then there is no longer going to be a /usr/bin/bash, binary or link. If this doesn't fill the bill I'll do a find and egrep for 2008 and bash. That will then give me a list of the stuff I need to remove from that tired compile from this past January. Shalom, John B. Brown. [EMAIL PROTECTED] 358 High Street, Buffalo, Wyoming 82834 "Freedom is not worth having if it does not include the freedom to make mistakes" Mahatma Gandhi "It is useless to attempt to reason a man out of what he was never reasoned into." Jonathan Swift "A man who does not know the truth is just an idiot but a man who knows the truth and calls it a lie is a crook." Bertolt Brecht "If any question why we died, tell them, because our fathers lied." Rudyard Kipling
Re: printf "%q" and $'...'
On 25 Nov 2009, at 16:27, Antonio Macchi wrote: >> imadev:~$ echo $'foo\0bar' >> foo > > > sorry... I'm a little bit confusing... look > > $ echo foo$'\0'bar > foobar > I expect $'\0' expands to the C-string ''. Which then gets added to the argument after 'foo' and before 'bar'.
Re: IFS handling and read
On 30 Nov 2009, at 11:34, Marc Herbert wrote: > Eric Blake a écrit : >> >> This is E4 in the FAQ: >> ftp://ftp.cwru.edu/pub/bash/FAQ >> >> POSIX permits, but does not require, that the final element of a pipeline >> be executed in a subshell. Bash uses the subshell, ksh does not. >> Variable assignments in a subshell do not affect the parent. > > I am regularly bitten by this. This is a major pain; it makes "read" very > inconvenient to use (whatever IFS is). > > Could this be changed in the future? Don't use pipelines to send streams to read. Use file redirection instead: Instead of ''command | read var'' Use ''read var < <(command)'' I hardly see a need to change the existing implementation.
Re: operators available in bash versions
On 30 Nov 2009, at 12:12, Gerard wrote: > > I apologize for asking what is probably a dumb question, but where can > I find a definitive listing of what features are available in each > version of Bash. > > For example, I only have access to Bash-4 on my system. I need to know > if " $(< " also works on Bash < 4. I also have a few questions > regarding array handling. > > I am running FreeBSD-7.2 and installed Bash via ports. > The following is not a bad reference: http://mywiki.wooledge.org/BashFAQ/061
Re: IFS handling and read
On 30 Nov 2009, at 14:10, Marc Herbert wrote: > > Lhunath (Maarten B.) a écrit : >> On 30 Nov 2009, at 11:34, Marc Herbert wrote: >> >>> Eric Blake a écrit : >>>> This is E4 in the FAQ: >>>> ftp://ftp.cwru.edu/pub/bash/FAQ > >> Instead of ''commands | read var'' >> Use ''read var < <(commands)'' >> I hardly see a need to change the existing implementation. > > As mentioned in the FAQ, ''read var < <(commands)'' is not portable. > > All alternatives in the FAQ (portable or not) are less readable than a > simple pipe. They are all more verbose and introduce an extra level of > nesting when you have only one "command". They all need to be read > "backwards" with respect to the execution flow. If you want to keep your > code readable, they practically all force you to define a function for > "commands" as soon as you have more than a few commands. > > Every entry in an FAQ is by mere definition a problem that many people > wast... spend time on. > > It is admittedly not a question of life or death but some other shells > apparently have it so why not bash? Just asking. Let me try to guess what your definition of portability is by assuming it means "will run in any POSIX shell". Firstly, if you are writing FOR the bash shell, you needn't worry about this type of portability. Putting bash in your hashbang means the script will only ever be interpreted by a bash shell, not any other POSIX shell. Secondly, if you do decide that for some reason you want to have your script interpretable by other POSIX shells (which means you avoid all other bash-specific features, too) your concern over portability still does not warrant the implementation being changed, as POSIX does not require shells to avoid subshelling components of a pipeline. So you still can't rely on other non-bash shells that are POSIX-compliant to treat your script's implementation the same. That said, the command substitution is an excellent alternative in any case for the pipeline-to-read problem. It is clean and has no side-effects. If your real issue is that many people struggle with this because they are newbies and haven't learned the intricacies of the shell yet, then surely this is not the first or biggest obstacle in that respect. Even (self-)proclaimed bash geniuses still fail at quoting expansions properly because they do not understand or appreciate the intricacies of word-splitting and pathname expansions.
Re: IFS handling and read
On 30 Nov 2009, at 15:56, Chris F.A. Johnson wrote: > > On Mon, 30 Nov 2009, Greg Wooledge wrote: > >> On Mon, Nov 30, 2009 at 11:46:03AM +0100, Lhunath (Maarten B.) wrote: >>> Don't use pipelines to send streams to read. Use file redirection instead: >>> >>> Instead of ''command | read var'' >>> Use ''read var < <(command)'' >>> >>> I hardly see a need to change the existing implementation. >> >> Or for the original problem case, use a here string: >> >> IFS=: read a b <<< "1:2" >> >> Between process substitutions (the <(command) thing) and here strings, >> you should be able to do all your reads without subshells. > > Or, to be portable, use a here document: > > IFS=: read a b <<. > 1:2 > . > > This works with the output of commands, too: > > IFS=- read year month day <<. > $(date +%Y-%m-%d) > . Note that 'read' is a bash feature; not a POSIX shell feature. In that sense, "read" alone is limiting your "portability". So portability in the meaning of POSIX is out of the question. Perhaps you're talking about backward compatibility instead of portability, in which case the only compatibility gain you get from using the more verbose heredoc over the herestring is compatibiltiy with pre-2.05b-alpha1 bash. Hardly worth it.
Re: IFS handling and read
On 30 Nov 2009, at 16:15, Chet Ramey wrote: > > Lhunath (Maarten B.) wrote: > >> Note that 'read' is a bash feature; not a POSIX shell feature. In that >> sense, "read" alone is limiting your "portability". So portability in the >> meaning of POSIX is out of the question. > > Pardon me? `read' is a feature of every historical shell and standardized > by Posix. The bash implementation is a superset of Posix. > > Chet > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer >``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ My bad. I was under the impression `read` was a Bourne shell-only thing and not standardized under POSIX.
bash --login in Cygwin environment does not use %HOME% when doing tilde expansion.
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: cygwin Compiler: i686-pc-cygwin-gcc Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='i688 6-pc-cygwin' -DCONF_VENDOR='pc' -DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS -I. -I/home/RLandheer/cygwin-contrr ib/bash/2.05b-16/bash-2.05b -I/home/RLandheer/cygwin-contrib/bash/2.05b-16/bash-2.05b/include -I/home/RLandhh eer/cygwin-contrib/bash/2.05b-16/bash-2.05b/lib -O2 uname output: CYGWIN_NT-5.0 WORK-ABB 1.5.10(0.116/4/2) 2004-05-25 22:07 i686 unknown unknown Cygwin Machine Type: i686-pc-cygwin Bash Version: 2.05b Patch Level: 0 Release Status: release Description: When invoking bash on a Windows machine with the --login option, tilde expansion is not done using the %HOME% environment variable. Repeat-By: Set HOME in the ControlPanel>System>Advanced>EnvironmentVariables>User variables for abb Invoke bash by calling bash.bat containing: @echo off c: chdir C:\bin\cygwin\bin bash --login -i Axel B. Bregnsbo ASIC Designer, M.Sc.EE +45 44855990 [EMAIL PROTECTED] -- entropy is time symmetric ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: echo -n
HI All, Thanks for your quick response. I have tried using the printf instead of echo. But the issue with printf is , the behaviour is not consistent with what echo prints for all the inputs i.e. In my script I am generically using echo for all the options. If I have to use printf instead of it should behave consistently . if echo * is passed to bash shell, the o/p shows the \t seperated values whereas with printf '%s' *, it won't display space separated output. Again printf '%s ' # behaviour is different from what echo # shows Thanks & Regards --Jyoti Jyoti Tenginakai AIX-Security Development Team IBM India Software Lab EGD 'D' Block Sixth Floor Off Indiranagar Koramangala Intermediate Ring Road Bangaluru - 560071 ph: 4177 extn: 7 Mail:jyoti@in.ibm.com From: Pierre Gaston To: Sangamesh Mallayya Cc: "bug-bash@gnu.org" , Jyoti B Tenginakai Date: 02/02/2017 08:45 PM Subject:Re: echo -n On Thu, Feb 2, 2017 at 11:02 AM, Sangamesh Mallayya < sangamesh.sw...@in.ibm.com> wrote: Hi, description: in bash echo -n , echo -e , echo -E has a special meaning. But we do not have a way in bash shell if we want to print -n , -e and -E using echo command. Other shells supports printing of -n/-e/-E options using echo command. For example with ksh # echo -n -n # with bash # echo -n # Please let us know if this a bug or do we have any other option to print -n ? Here is the environment details. version: bash 4.3 Hardware and Operating System P7 AIX Compiled with AIX xlc Thanks, -Sangamesh Not a bug, echo is not portable and posix recommends using printf e.g. printf '%s\n' -n
Re: echo -n
Thanks you all,
Again I see that this printf we can use. But there are some scenarios where
the o/p does not exactly match with echo. So still its good to have a way
to pirnt -n /-e/-E with echo. Can this be considered as bug and can this be
fixed?
Thanks & Regards
--Jyoti
Jyoti Tenginakai
AIX-Security Development Team
IBM India Software Lab
EGD 'D' Block Sixth Floor
Off Indiranagar Koramangala Intermediate Ring Road
Bangaluru - 560071
ph: 4177
extn: 7
Mail:jyoti@in.ibm.com
From: Chet Ramey
To: Jyoti B Tenginakai , Pierre Gaston
Cc: chet.ra...@case.edu, Sangamesh Mallayya
, "bug-bash@gnu.org"
Date: 02/02/2017 11:21 PM
Subject:Re: echo -n
On 2/2/17 11:56 AM, Jyoti B Tenginakai wrote:
> HI All,
>
> Thanks for your quick response.
>
> I have tried using the printf instead of echo. But the issue with printf
is
> , the behaviour is not consistent with what echo prints for all the
inputs
> i.e.
> In my script I am generically using echo for all the options. If I have
to
> use printf instead of it should behave consistently .
> if echo * is passed to bash shell, the o/p shows the \t seperated values
> whereas with printf '%s' *, it won't display space separated output.
Again
> printf '%s ' # behaviour is different from what echo # shows
echo()
{
builtin printf "%s\n" "$*"
}
You can make this more elaborate if you want.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.edu
http://cnswww.cns.cwru.edu/~chet/
bash vs sh / ticks appearing
Hi, I normally run a program on FreeBSD using its sh, and it runs fine. When I brought it over to Linux using bash its doing some strange stuff... SCRIPT: #!/bin/sh -x SCRIPT=$1 shift EMAIL=$1 echo $SCRIPT $SCRIPT 1>/tmp/mailifoutput.$$ 2>&1 sh/FreeBSD output: # ./script.sh "/usr/local/bin/otherprogram \"Param 1\" \"Param2\"" email + SCRIPT=/usr/local/bin/otherprogram "Param 1" "Param2" + shift + EMAIL=email + echo /usr/local/bin/otherprogram "Param 1" "Param2" /usr/local/bin/otherprogram "Param 1" "Param2" + /usr/local/bin/otherprogram "Param 1" "Param2" bash 3.00.15(1)-release/Centos Linux 2.6.9-42.0.10.EL [EMAIL PROTECTED] tmp]# ./script.sh "/usr/local/bin/otherprogram \"Param 1\" \"Param2\"" email + SCRIPT='/usr/local/bin/otherprogram "Param 1" "Param2"' + shift + EMAIL=email + echo /usr/local/bin/otherprogram '"Param' '1"' '"Param2"' /usr/local/bin/otherprogram "Param 1" "Param2" + /usr/local/bin/otherprogram '"Param' '1"' '"Param2"' Why does it insert the ticks, which end up making /usr/local/bin/otherprogram fail? I checked the FAQ for "tick" and didn't see anything. Thanks, Tuc
Re: bash vs sh / ticks appearing
> > "Tuc at T-B-O-H.NET" <[EMAIL PROTECTED]> writes: > > > When I brought it over to Linux using bash its doing > > some strange stuff... > > > > SCRIPT: > > > > #!/bin/sh -x > > > > SCRIPT=$1 > > shift > > EMAIL=$1 > > > > echo $SCRIPT > > $SCRIPT 1>/tmp/mailifoutput.$$ 2>&1 > > If you want the shell to reinterpret meta characters like quotes as part > of a parameter expansion, you need to use eval. > > > sh/FreeBSD output: > > > > # ./script.sh "/usr/local/bin/otherprogram \"Param 1\" \"Param2\"" email > > + SCRIPT=/usr/local/bin/otherprogram "Param 1" "Param2" > > + shift > > + EMAIL=email > > + echo /usr/local/bin/otherprogram "Param 1" "Param2" > > /usr/local/bin/otherprogram "Param 1" "Param2" > > + /usr/local/bin/otherprogram "Param 1" "Param2" > > The FreeBSD shell apparently displays the trace ambigously. > > > bash 3.00.15(1)-release/Centos Linux 2.6.9-42.0.10.EL > > [EMAIL PROTECTED] tmp]# ./script.sh "/usr/local/bin/otherprogram \"Param > > 1\" \"Param2\"" email > > + SCRIPT='/usr/local/bin/otherprogram "Param 1" "Param2"' > > + shift > > + EMAIL=email > > + echo /usr/local/bin/otherprogram '"Param' '1"' '"Param2"' > > /usr/local/bin/otherprogram "Param 1" "Param2" > > + /usr/local/bin/otherprogram '"Param' '1"' '"Param2"' > > > Why does it insert the ticks, > > They are single quotes and show you unambiguously the command that is > being exected. You can copy the line minus the leading + into the shell > command line and get exactly the same command executed. > > > which end up making /usr/local/bin/otherprogram fail? > > If the FreeBSD shell does not execute the script the same way as Bash > then it has a serious bug. > Ok... So FreeBSD sh has a bug, I'll take that up with them. Looks like the eval worked, thank you. Tuc
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
