Re: bug with edit-and-execute-command and multiline commands

Emanuele Torre wrote: > Also here is a paste with some examples by rwp: > https://paste.debian.net/plain/1206849 That paste is going to exire so here is the contents of it. I wanted to show exactly what characters were in the file being edited and therefore set VISUAL to od in order to du

Re: [OT] Linux Out-Of-Memory Killer

Marc Herbert wrote: > I suggest that Linux kids do not try this at home: the OutOfMemory killer > killed a few random processes of mine! Off-Topic for this mailing list but if so then you should configure your Linux kernel to avoid memory overcommit. I have previously ranted about this in some de

Re: Trouble with PS1 special characters between \[ and \]

Lluís Batlle i Rossell wrote: > I don't think this problem is related to any recent bash version > only. I've seen this since years I think. > > Nevertheless I'm using GNU bash, version 4.0.17(1)-release > (x86_64-unknown-linux-gnu) now. I am using 4.1.5(1)-release and I could not recreate your p

Re: ionice bash pid in bash_profile Fails

Roger wrote: > # See ionice manfile - give high priority to Bash > ionice -c 2 -n 0 -p `echo $$` You don't need to use backticks to echo out the value of $$. Just use it directly. ionice -c 2 -n 0 -p $$ Bob

Re: Clear Screen

Ajay Jain wrote: > I use bash on Xterm. > While working you press Ctrl-L, so that the screen gets cleared and > you see the currently line only. That is what clearing the does. It operates the same as the 'clear' command line program in clearing the screen. > But you may want to see the last out

Re: Clear Screen

Greg Wooledge wrote: > ... I can see where his question is coming from. If you're on an > rxvt or something, with a reasonably-sized scrollback buffer, and > you do a "tput clear" or its equivalent, you only lose the lines > that were on the visible part of the terminal at that time -- the > rest

Re: Recursively calling a bash script goes undetected and eats all system memory

Diggory Hardy wrote: > With a simple script such as that below, bash can enter an infinite > loop of eating memory until the system is rendered unusable: > > #!/bin/bash > PATH=~ > infinitely-recurse Yes, of course. It calls itself repeatedly and every copy consumes just a little more system res

Re: cd with multiple arguments?

Marc Herbert wrote: > If the shell was "real" programming language, then we would not have > such a massive ban on setuid scripts (I am not saying setuid is a > great feature, this is not the point here; the point is why is the > shell the only language under such a ban?) The shell isn't the only

Re: cd with multiple arguments?

Marc Herbert wrote: > Bob Proulx a écrit : > > The shell isn't the only one that introduces a security vulnerability > > on most systems when setuid. All interpreters are the same in that > > regard. On systems where you shouldn't suid scripts then you > >

Re: cd with multiple arguments?

Marc Herbert wrote: > Sorry I did not know about this race condition. This is more or less > the type of problems I had in mind: > > http://hea-www.harvard.edu/~fine/Tech/cgi-safe.html In addition to the fine recommendations from the others I wanted to specifically point out that the problems on

Re: Bug in shell: buffer overflow.

n...@lavabit.com wrote: > echo $((256**8)) > echo $((72057594037927936*128)) > echo $((1)) > etc. Unless great effort is made to perform math in arbitrary precision http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic all computer

Re: Bug in shell: buffer overflow.

Stephane CHAZELAS wrote: > Bob Proulx wrote: > [...] > > Your expressions above are overflowing the value of your system's > > maximum integer size. You can read the system's maximum integer size > > using getconf. > > > > $ getconf INT_MAX >

Re: client server date sync

JNY wrote: > I do not have access to NTP. > I have a script which will write the date of my server to a file and scp it > to my clients. Is there a way to use the contents of this file to update > the date of the clients? I hesitate to help you with this issue since stepping the clock as you prop

Re: Arithmetic expansion peculiarity

Joe Lightning wrote: > Description: > Bash doesn't like leading zeros in arithmetic expansion. > > Repeat-By: > echo $(( 09 - 1 )) This is bash FAQ E8. http://www.faqs.org/faqs/unix-faq/shell/bash/ Leading zeros denote octal. In octal t

Re: multi-line commands in the history get split when bash is quit

Slevin McGuigan wrote: > I am unsure whether or not this a bug. Anyhow, it is pretty annoying... > > I use simple multi-line scripts very often in bash and use vi mode > to edit them. By using > # shopt -s cmdhist > # shopt -s lithist > I can achive multi-line editing. Which is fine. > > But this

Re: [BUG] Bash not reacting to Ctrl-C

Oleg Nesterov wrote: > $ sh -c 'while true; do /bin/true; done' Be careful that 'sh' is actually 'bash'. It isn't on a lot of machines. To ensure that you are actually running bash you should call bash explicitly. (At least we can't assume you are running bash otherwise.) Is the behavior

Re: [BUG] Bash not reacting to Ctrl-C

Oleg Nesterov wrote: > Bob Proulx wrote: > > Is the behavior you observe any different for this case? > > $ bash -c 'while true; do /bin/true || exit 1; done' > > Or different for this case? > > $ bash -e -c 'while true; do /bin/true; done' >

Re: [BUG] Bash not reacting to Ctrl-C

Ingo Molnar wrote: > Could you try the reproducer please? > > Once you run it, try to stop it via Ctrl-C, and try to do this a > couple of times. I was not able to reproduce your problem using your (I believe to be slightly incorrect) test case: bash -c 'while true; do /bin/true; done' It was

Re: [BUG] Bash not reacting to Ctrl-C

Oleg Nesterov wrote: > That is why I provided another test-case, let me repeat it: Sorry but I missed seeing that the first time through or I would have commented. > #!./bash > perl -we '$SIG{INT} = sub {exit}; sleep' > echo "Hehe, I am going to sleep after ^C" > sleep 100

Re: Can someone explain this?

Dennis Williamson wrote: > Yes, do your quoting like this: > ssh localhost 'bash -c "cd /tmp; pwd"' I am a big fan of piping the script to the remote shell. $ echo "cd /tmp && pwd" | ssh example.com bash /tmp This has two advantages. One is that you can pick your shell on the remote host.

Re: how to workaroun 'nl' being added to input-line after 49 characters....

Linda Walsh wrote: > I'm having a problem, I think, due to my setting the prompt in > 'root' mode, to a different color. This results in me being able to > enter only 49 characters on the input line before it wraps to the next > line. It sounds like you have forgotten to enclose non-printing cha

Re: how to workaroun 'nl' being added to input-line after 49 characters....

Linda Walsh wrote: > Thanks for all the great suggestions on how to do the > encoding differently -- how about ideas on the input line > length being truncated? You seem to have misunderstood. Each and every one of those response has addressed your issue of input line length problems. The soluti

Re: how to workaroun 'nl' being added to input-line after 49 characters....

Linda Walsh wrote: > But anyway, something else is is awry. > > Now my root prompt, instead of being red, looks like: > > "\[\033[1m\]\[\033[31m\]Ishtar:root#\[\033[0m\] " > > ;-/ That will be due to incorrect quoting. Which suggestion did you implement? There were several. > What version of

Re: how to workaroun 'nl' being added to input-line after 49 characters....

Greg Wooledge wrote: > red=$(tput setaf 1) bold=$(tput bold) reset=$(tput sgr0) > PS1='\[$red\]\h\[$reset\]:\[$bold\]\w\[$reset\]\$ ' > > I tested that. It works. Nicely cleaned up! > PS1='\h:\w\$ ' For what it is worth I use something similar: PS1='\u@\h:\w\$ ' Bob

Re: bash tab variable expansion question?

gnu.bash.bug wrote: > Andreas Schwab wrote: > > Greg Wooledge wrote: > > > directory again, I typed "cd $OLDPWD/foo" -- and the $OLDPWD > > > became \$OLDPWD and did not do as I wished. > > > > Or use ~-/. > > What do you mean? > > ~-/. is no equal to $PWD No. But it is similar to $OLDPWD which

Re: Problem with open and rm

Barrie Stott wrote: > The script that follows is a cut down version of one that came from > elsewhere. Thank you for your bug report but neither 'open' nor 'rm' have anything to do with bash. This is not a bug in the bash shell. This mailing list is for bug reports in the bash shell. > cp /tmp/

Re: Bash

David Barnet wrote: > I am new to Ubuntu and Linux. I am trying to install Bash Shell If you are new then the easiest way is to use the package manager to install the software distribution's bash package. Something like the following will invoke sudo to get the access privilege and then APT to in

Re: a "script-relative" version of env

E R wrote: > - I've noticed that the argument passed to the she-bang interpreter > always seems to be an absolute path when commands are executed from a > shell. Are there cases where that will not be true? You might find reading Sven Mascheck's documentation interesting: http://www.in-ulm.de/

Re: last argument expansion has different output using the sh interpreter

Jacoby Hickerson wrote: > Although, I am curious, is this is a matter of sh being continually > updated to exclude all bash extensions or perhaps previously bash > didn't interpret #!/bin/sh to be the POSIX compliant interpreter? When bash is invoked as sh then bash complies with the POSIX sh. Th

Re: Copy in bash

vin_eets wrote: > I am using windows Then you will need to be aware of windows specific conventions. > I wanna copy a file in folder from one location to another folder in another > drive. > > Its working fine but not when file name contain spaces i.e. if the filename > is a b c > > What would

Re: Yet Another test option

Bruce Korb wrote: > I wouldn't know. I use it myself a bit and I am now playing with > Lustre fs code where they get it wrong because it is inconvenient to > get it right. After seeing that, I thought I'd suggest it. > ... > P.S. this check is really for any version below 2.6.27: > > - case

Re: Built-in printf Sits Awkwardly with UDP.

Ralph Corderoy wrote: > ... But a regular file ./foo on disk does look different and it > still seems odd that > printf '\n\n\n\n\n\n\n\n\n\n\n\n' >foo > does a dozen one-byte write(2)s. But the only reason you know that there is a long string of newlines is that your eye is looking over the

Re: How to do? Possible?

Linda Walsh wrote: > DJ Mills wrote: > >> Because a subshell cannot access the global variables of the parent. > > > > A subshell can access its parent's variables. foo=bar; ( echo "$foo" ) > > > > A sub process cannot, unless the variables are exported. It does > > not sound like you need to d

Re: How to do? Possible?

Linda Walsh wrote: > I didn't know why it behaved differently, but as you informed me > the difference is 'one's well-defined, and the other is not, I can > see why there 'could' be a difference... ;-) > > (which of course could change tomorrow, I suppose..) Not the second well defined case. It

Re: How to do? Possible?

Dennis Williamson wrote: > Linda Walsh wrote: > > GLOBAL="hi there" > > {foo=GLOBAL echo ${!foo}; } Note that this tickles a problem since foo isn't set before $foo is expanded. Use this following with a semicolon instead: GLOBAL="hi there" {foo=$GLOBAL; echo ${!foo}; } > You had a missing

Re: The mailing list software interfered with my content

Eric Blake wrote: > What, me urgent? wrote: > >In my most recent post, the mailing list software replaced the string > >"address@hidden" for a section of code snippet! > > Not the list software, but merely the web archiver that you are > viewing the mail in. If you are actually subscribed to the

Re: bug: return doesn't accept negative numbers

Eric Blake wrote: > Linda Walsh wrote: > >I guess I don't use negative return codes that often in shell, but > >I use them as exit codes reasonably often. For all of the reasons Eric mentioned you won't ever actually be able to see a negative result of an exit code however. > >'return' barfs on "

Re: bug: return doesn't accept negative numbers

Linda Walsh wrote: > How about portable code using: > > (exit -1); return > > It's ugly, but would seem to be the portable/official way to > do this. Exit codes should be in the range 0-255. Bob

Re: bug: return doesn't accept negative numbers

Linda Walsh wrote: > Bob Proulx wrote: > >Exit codes should be in the range 0-255. > --- > I suppose you don't realize that 'should' is a subjective opinion that > sometimes has little to do with objective reality. Sigh. Okay. Keep in mind that turn about

Re: equivalent of Linux readlink -f in pure bash?

Jon Seymour wrote: > Has anyone ever come across an equivalent to Linux's readlink -f that > is implemented purely in bash? > > (I need readlink's function on AIX where it doesn't seem to be available). Try this: ls -l /path/to/some/link | awk '{print$NF}' Sure it doesn't handle whitespace in

Re: equivalent of Linux readlink -f in pure bash?

Jon Seymour wrote: > readlink -f will fully resolve links in the path itself (rather than > link at the end of the path), which was the behaviour I needed. Ah, yes, well, as you could tell that was just a partial solution anyway. > It seems cd -P does most of what I need for directories and so >

Re: equivalent of Linux readlink -f in pure bash?

Jon Seymour wrote: > I always use sed for this purpose, so: > >$(cd "$dir"; ls -l "$base" | sed "s/.*->//") > > But, with pathological linking structures, this isn't quite enough - > particularly if the target of the link itself contains paths, some of > which may contain links :-) Agreed!

Re: equivalent of Linux readlink -f in pure bash?

Jon Seymour wrote: > readlink_f() > { > local path="$1" > test -z "$path" && echo "usage: readlink_f path" 1>&2 && exit 1; An extra ';' there that doesn't hurt but isn't needed. > local dir > > if test -L "$path" > then > local link=$(ls -l

Re: Coproc usage ... not understanding

Chet Ramey wrote: > Linda Walsh wrote: > > Ideas? > > You're probably running into grep (and sort, and sed) buffering its > output. I haven't been able to figure out a way past that. This may be a good point to mention this reference: http://www.pixelbeat.org/programming/stdio_buffering/ And

Re: Coproc usage ... not understanding

Greg Wooledge wrote: > Linda Walsh wrote: > > Bob Proulx wrote: > > >This may be a good point to mention this reference: > > > > > > http://www.pixelbeat.org/programming/stdio_buffering/ > > > Does it only work with gnu programs? I.e. how would

Re: Why bash command "cd //" set path "//" ?

Andrey Demykin wrote: > Why bash command "cd //" set path "//" ? > > double slashes only in first position > > I found this in all version of the bash. > Excuse me , if it is not a bug. > Possibly it is a feature. It is a feature. In the old days of the Apollo OS two leading slashes identified

Re: date command

s.pl...@juno.com wrote: > Bash Version: 4.1 > > When using date command with -d option, if the date is between > "2010-03-14 02:00" and "2010-03-14 02:59" inclusive, it gives an > "invalid date" error. You can test this with the following command: > echo $(date -d "2010-03-14 02:00" +%s)

Re: Time delay on command not found

Bill Gradwohl wrote: > when I typo a command, bash comes back with a command not found but > hangs the terminal for way too long. When you try to launch a command that does not exist anywhere on PATH then bash must search every directory component of PATH in order to look for the command. > How d

Re: problem with tail -f that need to add to each line constant string at the beginning of each line

dan12341234 wrote: > im running 4 scripts that perform ssh and tail -f on a file exist on 4 > servers and display on the screen. > (1 script per servers) > > ssh server1 tail -f /var/log/apache/access_log > ssh server2 tail -f /var/log/apache/access_log > ssh server3 tail -f /var/log/apache/access

Re: problem with tail -f that need to add to each line constant string at the beginning of each line

dan sas wrote: > what about if i want to run both commands simultaneous and send the > output to a file how can i do that This is getting further off topic for the bug bash mailing list. It really isn't too much about bash but just general help with how things work. A better place to ask these t

Re: script to provide responses to prompts (badly written C program)

Fernan Aguero wrote: > please accept my apologies, as this is my first post here. I'm sure > I'm asking a very stupid questions, but I'm kind of stuck with this > ... The bug-bash mailing list is not quite the right place for this type of question. Better to ask it in help-gnu-utils instead. The

Re: bash-completion between do and done

Peng Yu wrote: > Current, bash doesn't do command completion between do and done (for loop). > I'm wondering if this feature can be added. Of course bash does do command completion between do and done. Can you give an exact example test case? On what version of bash? Bob

Re: bash-completion between do and done

Chris F.A. Johnson wrote: >I can confirm it on 3.05b, 3.0 and 4.2: > > while [ ${n:=0} -lt 5 ] > do > se > > All I get is a beep. Hmm... It is still completing. But not command completion. It is doing filename completion instead of command completion. It is out of sync with the current

Re: exit status issue

Dallas Clement wrote: > Geir Hauge wrote: > > Add ''set -x'' at the start of the function and examine the output > > to see if it actually runs touch from PATH. > > The strace output is showing that the correct 'touch' is being executed. It would be a lot easier to use the 'sh -x' trace than usin

Re: exit status issue

DJ Mills wrote: > Bob Proulx wrote: > > sh -x ./scripttodebug > > I'm guessing you mean bash -x, not sh -x. Two different shells. It is a bash list so I probably should have said bash just to be politically correct. But the script doesn't use any bash specific constr

Re: help-b...@gnu.org mailing list

Chet Ramey wrote: > Clark J. Wang wrote: > > Chet Ramey wrote: > > I just created help-b...@gnu.org . I hope > > that it becomes the list where > > folks ask questions about bash and shell programming. Please socialize > > its existence and subscribe if y

Re: help-b...@gnu.org mailing list

Clark J. Wang wrote: > > This list distributes, to the active maintainers of BASH (the Bourne > > Again SHell), bug reports and fixes for, and suggestions for > > improvements in BASH. User discussion of BASH also occurs here. > > My understanding is Chet wants "User discussion of BASH" to go

Re: exit status issue

Dallas Clement wrote: > Okay, I simplified the script slightly, fixed the quoting and re-ran > with set -x. Here is the script and the output for the failure > scenario. Much more useful! Thanks. > + touch /mnt/array1/.accesstest > + CHK_RESULT=1 It looks to me that touch is failing and report

Re: exit status issue

Dallas Clement wrote: > > This doesn't (yet) look like a problem with bash. > > Admittedly bash seems to do the right thing if you go by the set -x > execution trace. If you go by that, it would indeed seem that the > call to touch is failing. I have a higher level of trust in -x output since I

Re: Severe memleak in sequence expressions?

Marc Schiffbauer wrote: > Greg Wooledge schrieb: > > Marc Schiffbauer wrote: > > > echo {0..1000}>/dev/null > > > > > > This makes my system starting to swap as bash will use several GiB of > > > memory. > > > > In my opinion, no. You're asking bash to generate a list of words from 0 > > to 1

Re: help-b...@gnu.org mailing list

Timothy Madden wrote: > Is the 'htlp-gnu-ut...@gnu.org' list on the help-bash info page > meant to be 'help-gnu-ut...@gnu.org' (note 'help' instead of 'htlp' > in the list name) ? > Can the list info on the web be updated ? Thanks for reporting that error. Fixed now. Bob

Re: Ill positioned 'until' keyword

Peng Yu wrote: > I looks a little wired why 'until' is the way it is now. > ... > until test-commands; do consequent-commands; done > while ! test-commands; do consequent-commands; done In the original Bourne shell there is no '!' operator. The 'until' was a way to negate the expression without u

Re: return values of bash scripts

Mike Frysinger wrote: > kc123 wrote: > > For example, my script below called crond.sh: > > ... > > content=`ps auxw | grep [c]rond| awk '{print $11}'` > > ... > > and output is: > > CONTENT: /bin/bash /bin/bash crond > > > > Why are there 2 extra arguments printed (/bin/bash) ? > > because you gr

Re: Is the description of set -- missing in man bash or at least difficult to find?

Greg Wooledge wrote: > Peng Yu wrote: > > As a reasonable search strategy to search for how to set $@ is to > > search for '$@' in man bash. > > There is a "Special Parameters" section. All of the parameters are listed > there without their leading $ prefix. For example, the documentation for >

Re: how to understand echo ${PATH#*:}

lina wrote: > how to understand > echo ${PATH#*:} > > the #*: > I don't get it. why the first path before : was gone. This is really a help-bash question. Please send all follow-ups there. The documentation says: ${parameter#word} ${parameter##word} Remove matching

Re: minor bug in bash

Zachary Miller wrote: > If write() is interrupted by a signal after it successfully writes > some data, it shall return the number of bytes written. > > consider SIGSTOP, which is non-maskable. when the process continues, wouldn't > this be a situation where the write was interrupted and thus

Re: test if shell is interactive

tapczan wrote: > #!/bin/bash > echo $- > > Execution: > > # ./a.sh > hB > > There is no 'i' so the session is non-interactive? > It was invoked from interactive. > Am I missing something? Shell scripts are not interactive. So what you are seeing above is correct. Bob

Re: test if shell is interactive

tapczan wrote: > Bob Proulx wrote: > > Shell scripts are not interactive. So what you are seeing above is > > correct. > > So, is there any way to test if script (a.sh) was invoked from interactive > session (human) or not (e.g. from cron)? I usually check if the standa

Re: excess braces ignored: bug or feature ?

Greg Wooledge wrote: > Mike Frysinger wrote: > > can't tell if this is a bug or a feature. > > > > FOO= BAR=bar > > : ${FOO:=${BAR} > > echo $FOO > > > > i'd expect an error, or FOO to contain those excess braces. instead, FOO > > is > > just "bar". > >

Re: Inconsistent quote and escape handling in substitution part of parameter expansions.

John Kearney wrote: > Eric Blake wrote: > >> [ "${test}" = "${test//"'"/"'"}" ] || exit 999 > > > > exit 999 is pointless. It is the same as exit 231 on some shells, > > and according to POSIX, it is allowed to be a syntax error in other > > shells. > > I was going for || exit "Doomsday" i,e. 666

Re: Bash scripting and large files: input with the read builtin from a redirection gives unexpected result with files larger than 2GB.

Chet Ramey wrote: > Jean-François Gagné wrote: > > uname output: Linux 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC > > 2011 x86_64 GNU/Linux > > Machine Type: x86_64-pc-linux-gnu > > Compile and run the attached program. If it prints out `4', which it does > on all of the Debian system

Re: using the variable name, GROUPS, in a read list

Greg Wooledge wrote: > Jim Meyering wrote: > > Is there a moral here, other than to avoid using special variable names? > > Probably to prefer lower-case variable names. > > You've nailed it. Or more precisely, avoid all-upper-case variable names, > because they tend to collide with environment v

Re: compgen is slow for large numbers of options

Richard Neill wrote: > I don't know for certain if this is a bug per se, but I think > "compgen -W" is much slower than it "should" be in the case of a > large (1+) number of options. I don't think this is a bug but just simply a misunderstanding of how much memory must be allocated in order t

Re: Possible bug: Race condition when calling external commands during trap handling

tillmann.crue...@telekom.de wrote: > I have produced the following script as a small example: A good small example! I do not understand the problem but I do have a question about one of the lines in it and a comment about another. > trap "kill $?; exit 0" INT TERM What did you intend with "kill

Re: cd // produces unexpected results

Stefano Lattarini wrote: > A little more info, quoting from the Autoconf manual: And I will respond to the quoted part from the autoconf manual realizing that Stefano isn't saying it but just passing the message along. :-) > POSIX lets implementations treat leading // specially, but requires le

Re: square bracket vs. curly brace character ranges

Marcel Giannelia wrote: > But the other day I was on a fresh install (hadn't set > LC_COLLATE=C yet, so I was in en_US.UTF-8), and this happened: > > $ ls > a A b B c C > $ ls {a..c} > a b c The above has nothing to do with file glob expansion. Using 'ls' there I think confuses the discu

Re: square bracket vs. curly brace character ranges

Hi Arnold, Aharon Robbins wrote: > You are ssuming here that everyone uses GLIBC. I don't know so I will ask. Isn't the problem endemic to glibc? Do other libc's such as HP-UX or AIX or other have this same issue? I am out of touch on the details of them these days. > Not so. The projects th

Re: a recursion bug

Yuxiang Cao wrote: > I use ulimit -s to find stack size, which is 8192kbytes. Then I use > valgrind to record the stack size which give me this information. > test.sh: xmalloc: ../bash/unwind_prot.c:308: cannot allocate 172 bytes > (8359936 bytes allocated) > So from the above information I think

Re: a recursion bug

Linda Walsh wrote: > Greg Wooledge wrote: > >Linda Walsh wrote: > >>>Yuxiang Cao wrote: > test.sh: xmalloc: ../bash/unwind_prot.c:308: cannot allocate > 172 bytes (8359936 bytes allocated) > > > >>Why shouldn't bash fail at the point it hits resource exhaustion and return > >>an error condi

Re: square bracket vs. curly brace character ranges

Linda Walsh wrote: > Chet Ramey wrote: > >http://lists.gnu.org/archive/html/bug-bash/2012-05/msg00086.html > >...Campaign For Rational Range Interpretation... > > The next version of bash will have a shell option to enable this > behavior. It's in the development snapshots if anyone wants to try >

Re: a recursion bug

Linda A. Walsh wrote: > Steven W. Orr wrote: > >I think there's a fundamental misunderstanding between the > >difference of an error code returned by a system call and the exit > >status of a process. They're two completely different things. > > It's not a fundamental misunderstanding.

Re: a recursion bug

Greg Wooledge wrote: > imadev:~$ bash-4.2.28 -c 'a() { echo "$1"; a $(($1+1)); }; a 1' 2>&1 | tail > Pid 4466 received a SIGSEGV for stack growth failure. > Possible causes: insufficient memory or swap space, > or stack size exceeded maxssiz. > 6534 > 6535 > 6536 > 6537 > 6538 > 6539 > 6540 > 6541

Re: a recursion bug

Chet Ramey wrote: > > Pid 4466 received a SIGSEGV for stack growth failure. > > Possible causes: insufficient memory or swap space, > > or stack size exceeded maxssiz. > > There's not actually anything you can do about that except use ulimit to > get as much stack space as you can. Well... There

Re: Clarification needed on signal spec EXIT

Francis Moreau wrote: > -- > main_cleanup () { echo main cleanup; } > submain_cleanup () { echo sub cleanup; } > > trap main_cleanup EXIT > > task_in_background () { > echo "subshell $BASHPID" > > while :; do > # echo "FOO" > sleep 1 >

Re: documentation bug (uid resetting in posix mode)

Stefano Lattarini wrote: > Anyway, my /bin/sh is bash ... > $ ls -l /bin/sh > lrwxrwxrwx 1 root root 4 Jul 8 2010 /bin/sh -> bash > I'm on Debian Unstable BTW (sorry for not specifying that earlier). Let me say this aside on the issue since there is opportunity for some confusion. On Debian

Re: documentation bug (uid resetting in posix mode)

Stefano Lattarini wrote: > Hi Bob, thanks for the tips. However ... > > Bob Proulx wrote: > > Stefano Lattarini wrote: > >> Anyway, my /bin/sh is bash ... > >> $ ls -l /bin/sh > >> lrwxrwxrwx 1 root root 4 Jul 8 2010 /bin/sh -> bash > >>

Re: documentation bug (uid resetting in posix mode)

Andreas Schwab wrote: > Stefano Lattarini writes: > > If it ain't broken, don't fix it ;-) > > As you found out, it _is_ broken. Okay. But broken which way? Which of these are you saying: 1. Broken because bash normally drops privileges? Or: 2. Broken because called as /bin/sh Debian patched

Re: Any chance of multi-dimensional arrays?

Rene Herman wrote: > All I want additionally is multi-dimensional arrays... There are various naming conventions and schemes to simulate multi-dimensional arrays using single dimension arrays. Since you want to continue with the shell and the shell has not (yet) provided multi-dimensional arrays

Re: Cron jobs, env vars, and group ID ... oh my

Mun wrote: > #! /bin/bash > newgrp group1 > id -g -n // This shows my login group ID, not group1 The 'newgrp' command spawns a new child shell. After that child shell exits the new group evaporates. The rest of the script continues with the previous id. This is a common misunderstan

Re: Question about the return value of 'local'

Francis Moreau wrote: > I found that the return value of 'local' keyword is counter intuitive > when the value of the assignment is an expression returning false. In > that case the return value of local is still true. For example: > > local foo=$(echo bar; false) > > returns true Yes. The cr

Re: |& in bash?

Greg Wooledge wrote: > On Tue, Jan 22, 2013 at 06:56:31AM -0500, Steven W. Orr wrote: > > By that logic, > > [...alternate possibility omitted...] > > So, in chronological order: > [...list of actions omitted...] I think the take-away here is that the shell evolved to require 142 unique command l

Re: |& in bash?

Greg Wooledge wrote: > It kinda reminds me of the Linux newcomers who don't know how to do > gzip -dc foo.tar.gz | tar xvf - (and so on) because they've been trained > to use GNU tar's "z" flag instead, and therefore that piece of their > education hasn't been absorbed yet. Just like: grep -r P

Re: When cd'd into a symlinked directory, directory completion can sometimes erroneously parse ../

Chet Ramey wrote: > i336 wrote: > > mkdir -p dir1/dir2 > > ln -s dir1/dir2 ouch > > touch idontexist > > ls # ^ to see dir & files & prove they really exist :P > > cd ouch > > ls ../ido > > ... > > Filename completion uses whatever file system view -- logical or physical > -- that you have selecte

Re: Shouldn't this script terminate on ^C?

Nikolaus Schulz wrote: > Please consider this bash script: > > : | while true; do sleep 1; done > echo "After loop" > > If I hit ^C while it runs, shouln't it terminate? > > I have tested bash versions 4.2.37(1)-release, 4.1.5(1)-release, > and 3.2.39(1)-release. (Debian Sid, Squeeze and Len

Re: export in posix mode

Eric Blake wrote: > James Mason wrote: > > I certainly could be doing something wrong, but it looks to me like bash > > - when in Posix mode - does not suppress the "-n" option for export. > > The version of bash that I'm looking at is 3.2.25. > > So what? Putting bash in posix mode does not re

Re: export in posix mode

Chet Ramey wrote: > Keep in mind that posh is overly strict in some areas (e.g., it throws > an error on `exit 1'). It may not be useful in isolation. As I did mention I have found that posh is somewhat less than useful in Real Life. But you say it throws an error on exit 1? $ cat >/tmp/trial

Re: export in posix mode

James Mason wrote: > We considered setting up another shell as the implementation of > "/bin/sh", but that's hazardous in the context of vast amounts of > boot-time initialization scripting that hasn't been vetted as to > avoidance of bash-isms. You appear to be doing product QA. Awesome! Have y

Re: export in posix mode

Chet Ramey wrote: > I don't know what version you're using; I have 0.11. > > $ ./posh > \[\]${HOST}($SHLVL)\$ exit 1 > ./posh: exit: bad number > > $ ./posh > \[\]${HOST}($SHLVL)\$ exit 10 > ./posh: exit: bad number > $ echo $? > 1 I am using 0.11 too. I was using the Debian packaged version.

Re: Should this be this way?

Chet Ramey wrote: > Linda Walsh wrote: > > Greg Wooledge wrote: > >>> How often, when at a terminal, do you type #!/bin/bash before every line? > >> > >> When I've put the contents into a file? Every. single. time. > > --- > > Then when I press 'v' to edit the command line in a text editor -- > >

Re: If rbash is worthless, why not remove it and decrease bloat?

Linda Walsh wrote: > Greg Wooledge wrote: > > Honestly, a "restricted shell" is usually a pitiful thing that would be > > a joke, except it's not even funny. > Chet answered this in context: > Chet Ramey wrote: > > Posix has chosen not to standardize the restricted shell, either `rsh' or >

  1   2   3   4   5   6   >