[sr #111047] Value of BASHPID changes when inside a here-document
URL: <https://savannah.gnu.org/support/?111047> Summary: Value of BASHPID changes when inside a here-document Group: The GNU Bourne-Again SHell Submitter: rmwaite Submitted: Thu 04 Apr 2024 09:57:30 PM UTC Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: Mac OS ___ Follow-up Comments: --- Date: Thu 04 Apr 2024 09:57:30 PM UTC By: Richard Waite I noticed that BASHPID expands to a different PID value compared to the value outside of it. $ echo $BASHPID 77362 $ cat << EOF > $BASHPID > EOF 77507 Does variable expansion for here-documents occur in a subshell? Checking the value of BASH_SUBSHELL seems to indicate no: $ cat << EOF > $BASH_SUBSHELL > EOF 0 However, I did find this note about BASHPID in bash(1): > This differs from +nomarkup+$$-nomarkup- under certain circumstances, such as subshells that do not require bash to be re-initialized. Are here-documents one of these circumstances? I suspect this is due to the way here-documents are handled internally, but any insight into this behavior would be greatly appreciated. ___ Reply to this item at: <https://savannah.gnu.org/support/?111047> ___ Message sent via Savannah https://savannah.gnu.org/
Parallel make race in 5.1
Hi,
In bash 5.1 we're seeing a parallel make race during build, as found a
couple of times in our automated CI for Yocto Project:
https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/1720/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/2969/steps/25/logs/stdio
The issue is around pipesize.h which in 5.1 can be built by two
different triggers, builtins/ulimit.o or redir.o.
They can race against each other and rewrite files causing the above
failure.
We added a bit of a hacky workaround:
Index: bash-5.1/Makefile.in
===
--- bash-5.1.orig/Makefile.in
+++ bash-5.1/Makefile.in
@@ -746,7 +746,7 @@ ${DEFDIR}/bashgetopt.o: $(BUILTIN_SRCDIR
${DEFDIR}/builtext.h: $(BUILTIN_DEFS)
@(cd $(DEFDIR) && $(MAKE) $(MFLAGS) builtext.h ) || exit 1
-${DEFDIR}/pipesize.h:
+${DEFDIR}/pipesize.h: $(BUILTINS_LIBRARY)
@(cd $(DEFDIR) && $(MAKE) $(MFLAGS) pipesize.h ) || exit 1
$(SDIR)/man2html$(EXEEXT): ${SUPPORT_SRC}/man2html.c
Cheers,
Richard
Bug? Bash manual not indexable by search engines
There was discussion on Twitter today (https://twitter.com/PttPrgrmmr/status/1132351142938185728) about how the Bash manual appears to not be indexable by search engines. https://www.gnu.org/software/bash/manual/bashref.html redirects to https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html, and www.gnu.org/robots.txt has "Disallow: /savannah-checkouts/" We reasoned that this probably wasn't deliberate and wanted to report it.
Re: Syslog output from bash
That was exactly it. I kept thinking of openlog as opening a pointer to a file. Thanks, all for you insights. On Aug 23, 2016 9:44 AM, "Chet Ramey" <chet.ra...@case.edu> wrote: > On 8/22/16 4:10 PM, Richard Lohman wrote: > > Hey all: > > > > In my attempts to log commands from bash via syslog, I've come upon a > snag. > > The output is of the form: > > Mmm dd HH:MM:SS hostname -bash: command > > This was obtained by uncommenting the define in config-top.h and changing > > the call to syslog in bashhist.c as such: > > syslog(SYSLOG_FACILITY|SYSLOG_LEVEL, "%s", line); > > > > Problem is, I'd like the output to resemble other syslog messages: > > Mmm dd HH:MM:SS hostname bash[pid]: command > > And ultimately drop the username in as well. Since only bash is logging > in > > this format, I'm guessing there is something in the bash source tree > > impacting the format, but I can't seem to find it. > > Whether or not the pid is printed as part of the message (once you remove > it from the default bash syslog format string) is a property of the options > passed to openlog(). bash-4.4 has an OPENLOG_OPTS define, and a > corresponding call to openlog() that uses it, to set this. Bash-4.3 > doesn't call openlog, so it uses the system's syslog defaults. > > If you want to print the username instead of the uid, use > current_user.user_name instead of current_user.uid, which the original bash > syslog call uses. You've already changed the format, so you can drop > another %s in there and use current_user.user_name. > > Chet > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~ > chet/ >
Syslog output from bash
Hey all:
In my attempts to log commands from bash via syslog, I've come upon a snag.
The output is of the form:
Mmm dd HH:MM:SS hostname -bash: command
This was obtained by uncommenting the define in config-top.h and changing
the call to syslog in bashhist.c as such:
syslog(SYSLOG_FACILITY|SYSLOG_LEVEL, "%s", line);
Problem is, I'd like the output to resemble other syslog messages:
Mmm dd HH:MM:SS hostname bash[pid]: command
And ultimately drop the username in as well. Since only bash is logging in
this format, I'm guessing there is something in the bash source tree
impacting the format, but I can't seem to find it.
As far as the user name, I cobbled a bit of code that will get this for me:
register structure password *pw;
register uid_t uid;
uid=geteuid();
pw=getpwuid(uid);
If(pw) {
return(pw->pw_name); }
else {
//handle the error... }
This works to obtain the username, but seems a little heavy-handed. Is
there something more expedient, by chance?
Thanks in advance,
Rich
Logging bash commands to a specific file
Hi, all: I've seen this topic come up a time or two, but the responses don't quit match my situation. ...and, if there's a better place to post, please do feel free to let me know. I need to log all commands entered at the shell for all users on a host (business need, not technical). There is a pre-defined process in place, but no docs/history on how it was implemented. History files don't meet expectations because they can be modified by the user. Likewise, syslog isn't ideal, as shell commands get intermingled with other commands. I have a specific output format I need to stick to for consistency that it not something one would find in an existing solution (Mon day hh:mm:ss hostname process name: [username] command+args). Finally, only root should have read access to the log (sits in /var). I already took a stab at it, and updated bashhist.c to open and write to a file in the format I need, but as soon as I set the permissions on the target to 660, it breaks as the newly-compiled bash runs as the user, and can no longer write to the file. So, with all that, any thoughts? I'm happy to work within the source, or apply some external solution. Thanks in advance, Rich
[rvskmbr...@gmail.com: Re: Type-in programs using BASH]
; =
nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; =
nbsp; nbsp; nbsp; nbsp; nbsp; type [-afptP] name [name =
...]/font/divdiv class=3D style=3Dmargin: 0px;font =
face=3DDejaVu Sans Mono class=3Dnbsp;export [-fn] [name[=3Dvalue] =
...] or exgt;nbsp; typeset [-aAfFgilrtux] [-p] =
name[=3Dvagt;/font/divdiv class=3D style=3Dmargin: 0px;font =
face=3DDejaVu Sans Mono class=3Dnbsp;false nbsp; nbsp; nbsp; =
nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; =
nbsp; nbsp; nbsp; nbsp; ulimit [-SHabcdefilmnpqrstuvxT] =
[limgt;/font/divdiv class=3D style=3Dmargin: 0px;font =
face=3DDejaVu Sans Mono class=3Dnbsp;fc [-e ename] [-lnr] [first] =
[last] ogt;nbsp; umask [-p] [-S] [mode]/font/divdiv class=3D =
style=3Dmargin: 0px;font face=3DDejaVu Sans Mono class=3Dnbsp;fg=
[job_spec] nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; =
nbsp; nbsp; nbsp; nbsp; nbsp; unalias [-a] name [name =
...]/font/divdiv class=3D style=3Dmargin: 0px;font =
face=3DDejaVu Sans Mono class=3Dnbsp;for NAME [in WORDS ... ] ; do =
COMMANDgt;nbsp; unset [-f] [-v] [-n] [name ...]/font/divdiv =
class=3D style=3Dmargin: 0px;font face=3DDejaVu Sans Mono =
class=3Dnbsp;for (( exp1; exp2; exp3 )); do COMMANgt;nbsp; until =
COMMANDS; do COMMANDS; done/font/divdiv class=3D style=3Dmargin: =
0px;font face=3DDejaVu Sans Mono class=3Dnbsp;function name { =
COMMANDS ; } or name gt;nbsp; variables - Names and meanings of =
sogt;/font/divdiv class=3D style=3Dmargin: 0px;font =
face=3DDejaVu Sans Mono class=3Dnbsp;getopts optstring name =
[arg]nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; wait [-n] [id =
...]/font/divdiv class=3D style=3Dmargin: 0px;font =
face=3DDejaVu Sans Mono class=3Dnbsp;hash [-lr] [-p pathname] =
[-dt] [name gt;nbsp; while COMMANDS; do COMMANDS; =
done/font/divdiv class=3D style=3Dmargin: 0px;font =
face=3DDejaVu Sans Mono class=3Dnbsp;help [-dms] [pattern ...] =
nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; { COMMANDS ; =
}/font/div/divdiv class=3D style=3Dmargin: 0px;font =
face=3DDejaVu Sans class=3Dbr class=3D/font/divdiv =
class=3D style=3Dmargin: 0px;font face=3DDejaVu Sans class=3DIn=
this model, no command is executed until the here identifier is read, =
and another shell is spawned to execute all commands.span =
class=3DApple-converted-spacenbsp;/spanb class=3DOnly one line =
at a time can be edited./b/font/divdiv class=3D style=3Dmargin: =
0px;font face=3DDejaVu Sans class=3Dbr =
class=3D/font/divdiv class=3D style=3Dmargin: 0px;font =
face=3DDejaVu Sans class=3DTo enable the spread of this quite =
obscure (as far as I know) way to execute BASH, I am attaching the draft =
exception I mentioned earlier in this message. (I hereby transfer =
copyright over the same to the Free Software =
Foundation.)/font/divdiv class=3D style=3Dmargin: 0px;font =
face=3DDejaVu Sans class=3Dbr class=3D/font/divdiv =
class=3D style=3Dmargin: 0px;font face=3DDejaVu Sans class=3DIf=
one wants to save the typed program so it can be executed again later, =
he should usenbsp;/fontfont face=3DDejaVu Sans Mono class=3Db =
class=3Dcat lt;lt;'EOF' gt;input.sh | bash/b/fontfont =
face=3DDejaVu Sans class=3Dspan =
class=3DApple-converted-spacenbsp;/spaninstead, =
wherenbsp;=E2=80=9Cinput.sh=E2=80=9D is the name of the output =
file.span class=3DApple-converted-spacenbsp;/spanb class=3D(The=
file will be overwritten without warning if it already =
exists.)/b/font/divdiv class=3D style=3Dmargin: 0px;font =
face=3DDejaVu Sans class=3Db class=3Dbr =
class=3D/b/font/divdiv class=3D style=3Dmargin: =
0px;/div/divspan =
id=3Dcid:83ECD2E0-FDC2-4C23-A600-C60218A0EF62@hsd1.wa.comcast.net. =
class=3Dlt;type-in-exception.txtgt;/spandiv class=3D =
style=3Dword-wrap: break-word; -webkit-nbsp-mode: space; =
- -webkit-line-break: after-white-space;div class=3D style=3Dmargin: =
0px;/divdiv class=3D style=3Dmargin: 0px;font face=3DDejaVu =
Sans class=3Dbr class=3D/font/divdiv class=3D =
style=3Dmargin: 0px;font face=3DDejaVu Sans class=3DI thank you =
for your efforts, and I encourage you to spread the news about this =
tospan class=3DApple-converted-spacenbsp;/spani class=3DLinux =
Format/inbsp;and other GNU/Linux-related magazines, and to individual =
programmers, so they can publish Bourne Again Shell programs for =
execution in this way./font/divdiv class=3D style=3Dmargin: =
0px;font face=3DDejaVu Sans class=3Dbr =
class=3D/font/divdiv class=3D style=3Dmargin: 0px;font =
face=3DDejaVu Sans class=3DSincerely,/font/divdiv class=3D =
style=3Dmargin: 0px;font face=3DDejaVu Sans class=3Dbr =
class=3D/font/divdiv class=3D style=3Dmargin: 0px;font =
face=3DDejaVu Sans class=3DRyan =
Cunningham/font/div/div/div/blockquote/div/div/div/blockq=
uote/divbr class=3D/div/div/div/div/blockquote/divbr =
class=3D/div/div/div/blockquote/divbr =
class=3D/div/div/div/div/blockquote/divbr =
class=3D/div/body/html=
- --Apple-Mail=_51A7C042-5A82-40D5-B8FA-5586341517FA--
- --Apple-Mail=_0FFE68EB-40A8-4B26-B362-C6D78F1EEECE--
--- End of forwarded message ---
--
Dr Richard
bash bug with read -s command
steps to produce hide cursor setterm -cursor off call the bash built-in read command as follows: silent, wait 1 second, read 1 character to variable KEY read -s -t 1 -n 1 KEY while the read command is in a loop, control + c is trapped successfully and the cursor is un-hidden setterm -cursor on expected results: cursor is visible and typed keys are echoed to screen as before actual results: cursor is visible, keys are no-longer echoed to the screen until terminal is closed additional notes command: setterm -default cannot fix os: fedora 21 bash version: bash-4.3.30-2.fc21.x86_64 tested in various terminal emulators, and the console (alt+Fn, where n=1-8) workaround remove silent -s from read command sample script http://pastebin.com/EhCNaWmT
Re: Does declaring an array variable initialize it?
Chet Ramey chet.ra...@case.edu writes: On 3/20/14 12:41 AM, Richard Tollerton wrote: I suppose that this change in behavior makes array variables more consistent with normal variables, but I couldn't find anything in CHANGES which obviously relates to this, so I'm not sure if this is a bug or not. There is this, in the list of changes in bash-4.3-beta: f. Fixed several cases where `invisible' variables (variables with attributes but no values, which are technically unset) were treated incorrectly. D'oh! Was I always mistaken in figuring that declaring an array also initialized it? A variable is not set until it has been assigned a value. This was always true, and always supposed to apply to array variables as it did to scalars. bash-4.2 had a number of inconsistencies here, and I fixed some number of those. I'm sure some still remain. This topic has come up several times in the past, most recently a couple of weeks ago: http://lists.gnu.org/archive/html/bug-bash/2013-01/msg00068.html http://lists.gnu.org/archive/html/bug-bash/2013-11/msg0.html http://lists.gnu.org/archive/html/bug-bash/2014-03/msg00052.html Understood. Looks like I have some more (worthwhile) reading to do. Thanks! 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/ -- Richard Tollerton rich.toller...@ni.com
Does declaring an array variable initialize it?
Old behavior, bash 4.2.45:
$ bash -c 'set -u; echo ${#arr1[@]}'; \
bash -c 'set -u; declare var1; echo ${#var1}'; \
bash -c 'set -u; declare -a arr2; echo ${#arr2[@]}'
bash: arr1: unbound variable
bash: var1: unbound variable
0
New behavior, bash 4.3:
$ bash -c 'set -u; echo ${#arr1[@]}'; \
bash -c 'set -u; declare var1; echo ${#var1}'; \
bash -c 'set -u; declare -a arr2; echo ${#arr2[@]}'
bash: arr1: unbound variable
bash: var1: unbound variable
bash: arr2: unbound variable
I suppose that this change in behavior makes array variables more
consistent with normal variables, but I couldn't find anything in
CHANGES which obviously relates to this, so I'm not sure if this is a
bug or not.
Was I always mistaken in figuring that declaring an array also
initialized it?
--
Richard Tollerton rich.toller...@ni.com
bug-report/request: allow set +n to re-enable commands.
Dear All, Might I suggest/request that set +n should undo the effect of set -n ? For example: #!/bin/bash echo one set -n echo two set +n echo three would print: one three Here's why I think it would be useful: 1. Bash doesn't have a block-comment mechanism, like /* ... */ and this would provide one. 2. The documentation for help set says that flags can be undone with +, thus the inverse of -n is +n. (though in contradiction , it also says that subsequent commands (which would include the set are ignored) 3. It would allow for a neat hack with polyglots. For example: #!/bin/bash -n ?php /* set +n echo Hello, from Bash exec /usr/bin/php -ddisplay_errors=E_ALL $0 $@ */ echo Hello from PHP .phpversion().\n; //continue in PHP till the end of the file. ? (there is actually a serious purpose to this, namely to create a php-cli script that shows all errors, despite the settings in the system-wide php-ini file) Example 3 works if you remove the -n and set +n parts, though it then emits an annoying complaint about ?php: No such file or directory Thank you for your consideration, Best wishes, Richard
SIGSEGV on local -a GROUPS=(...) in function
This is probably not a good thing to be doing in the first place (I ran
into this before realizing that GROUPS was a special variable):
#!/bin/bash
crashy () { local -a GROUPS=(a b); }
crashy
But it probably shouldn't be doing this (tested in bash 4.2.42 on
archlinux x86_64, and bash 4.2.10 on armv7a):
$ ./bash-crash.sh
Segmentation fault (core dumped)
Here's a stack trace:
(gdb) run ~/bash-crash.sh
Starting program: /home/rtollert/abs/bash/src/bash-4.2/bash ~/bash-crash.sh
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need set solib-search-path or set sysroot?
Program received signal SIGSEGV, Segmentation fault.
assign_compound_array_list (var=var@entry=0x0, nlist=nlist@entry=0x6e8030,
flags=flags@entry=2)
at arrayfunc.c:516
516 else if (assoc_p (var))
(gdb) bt
#0 assign_compound_array_list (var=var@entry=0x0, nlist=nlist@entry=0x6e8030,
flags=flags@entry=2)
at arrayfunc.c:516
#1 0x00442210 in do_compound_assignment (flags=2, value=0x6e7980 a
b,
name=0x6e7960 GROUPS) at subst.c:2715
#2 do_assignment_internal (word=optimized out, expand=expand@entry=1) at
subst.c:2815
#3 0x00442315 in do_word_assignment (word=optimized out,
flags=flags@entry=0)
at subst.c:2866
#4 0x0044878c in shell_expand_word_list (eflags=31, tlist=0x6e7880) at
subst.c:9230
#5 expand_word_list_internal (list=optimized out, eflags=eflags@entry=31) at
subst.c:9362
#6 0x00448d75 in expand_words (list=optimized out) at subst.c:8984
#7 0x00429acb in execute_simple_command (fds_to_close=optimized out,
async=optimized out, pipe_out=-1, pipe_in=-1, simple_command=0x6e72d0) at
execute_cmd.c:3775
#8 execute_command_internal (command=optimized out,
asynchronous=asynchronous@entry=0,
pipe_in=pipe_in@entry=-1, pipe_out=pipe_out@entry=-1,
fds_to_close=fds_to_close@entry=0x6e55b0)
at execute_cmd.c:735
#9 0x0042b8f6 in execute_command_internal
(command=command@entry=0x6e6e70,
asynchronous=asynchronous@entry=0, pipe_in=pipe_in@entry=-1,
pipe_out=pipe_out@entry=-1,
fds_to_close=fds_to_close@entry=0x6e55b0) at execute_cmd.c:883
#10 0x0042c498 in execute_function (var=var@entry=0x6e6fe0,
words=words@entry=0x6e6c60,
flags=flags@entry=0, fds_to_close=fds_to_close@entry=0x6e55b0,
async=async@entry=0,
subshell=subshell@entry=0) at execute_cmd.c:4306
#11 0x0042a33b in execute_builtin_or_function (flags=0,
fds_to_close=0x6e55b0, redirects=0x0,
var=0x6e6fe0, builtin=0x0, words=0x6e6c60) at execute_cmd.c:4536
#12 execute_simple_command (fds_to_close=optimized out, async=optimized
out, pipe_out=-256,
pipe_in=0, simple_command=0x0) at execute_cmd.c:3944
#13 execute_command_internal (command=command@entry=0x6e5580,
asynchronous=asynchronous@entry=0,
pipe_in=pipe_in@entry=-1, pipe_out=pipe_out@entry=-1,
fds_to_close=fds_to_close@entry=0x6e55b0)
at execute_cmd.c:735
#14 0x0042d642 in execute_command (command=0x6e5580) at
execute_cmd.c:382
#15 0x0041926e in reader_loop () at eval.c:152
#16 0x00418d50 in main (argc=2, argv=0x7fffe358,
env=0x7fffe370) at shell.c:749
Re: compgen is slow for large numbers of options
Dear Bob, Thanks for your explanation. I do understand what is going on and why. But my point was that compgen has an implicit internal grep that is much less efficient than actual grep. Why is the performance of compgen's sorting/filtering algorithm so much worse than grep's ? Both of them start with a large list, and filter it to a small one. At any rate, might I suggest this is worthy of a line or two of documentation in the compgen manual? 40,000 possible completions is not necessarily unreasonable. [In this case, urpmi, as used by Mandriva/Mageia has had it wrong for some time.] Best wishes, Richard Message: 4 Date: Wed, 14 Mar 2012 13:40:36 -0600 From: Bob Proulxb...@proulx.com To: bug-bash@gnu.org Subject: Re: compgen is slow for large numbers of options Message-ID:20120314194036.ga12...@hysteria.proulx.com Content-Type: text/plain; charset=us-ascii 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 to generate `seq 1 50`. For example (on a fast i7 2700 CPU), I measure: compgen -W `seq 1 5` 1794#3.83 s compgen -W `seq 1 5 | grep 1794` #0.019 s In these examples, I'm using `seq` as a trivial way to generate some data, and picking 1794 as a totally arbitrary match. Right. But in the first case you are generating 288,894 bytes of data and in the second case 89 bytes of data. That is a large difference. You could probably speed it up a small amount more by using grep -x -F and avoid the common substring matches. And perhaps more depending upon your environment with LC_ALL=C to avoid charset issues. In the first example, compgen is doing the filtering, whereas in the 2nd, I obtain the same result very much faster with grep. Yes, since grep is reducing the argument size to 89 bytes. That makes perfect sense to me. Anything that processes 89 bytes is going to be much faster than anything that processes 288,894 bytes. If I increase the upper number by a factor of 10, to 50, these times become, 436 s (yes, really, 7 minutes!) and 0.20 s That is an increase in argument size to 3,388,895 bytes and there will be associated memory overhead to all of that increasing the size on top of that value too. Three plus megabytes of memory just for the creation of the argument list and then it must be processed. That isn't going to be fast. You would do much better if you filtered that list down to something reasonable. respectively. This suggests that the algorithm used by compgen is O(n^2) whereas the algorithm used by grep is 0(1). On the counter it suggests that the algorithm you are using, one of fully allocating all memory, is inefficient. Whereas using grep as a filter to reduce that memory to 89 bytes is of course more efficient. I wrote a response on a similar issue previously. Instead of posting it again let me post a pointer to the previous message. http://lists.gnu.org/archive/html/bug-bash/2011-11/msg00189.html Bob
compgen is slow for large numbers of options
Dear All, 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. For example (on a fast i7 2700 CPU), I measure: compgen -W `seq 1 5` 1794#3.83 s compgen -W `seq 1 5 | grep 1794` #0.019 s In these examples, I'm using `seq` as a trivial way to generate some data, and picking 1794 as a totally arbitrary match. In the first example, compgen is doing the filtering, whereas in the 2nd, I obtain the same result very much faster with grep. If I increase the upper number by a factor of 10, to 50, these times become, 436 s (yes, really, 7 minutes!) and 0.20 s respectively. This suggests that the algorithm used by compgen is O(n^2) whereas the algorithm used by grep is 0(1). For a real world example, see: https://bugs.mageia.org/show_bug.cgi?id=373#c8 in which we are using completion on package-management. In this case, the number is 43031. I hope this is helpful. Richard
Re: Error building mkbuiltins on ia64-hp-hpux11.23
On Fri, 2011 Apr 22 10:08-0400, Chet Ramey wrote: That's not what actually happens. CCFLAGS and CCFLAGS_FOR_BUILD share a common set of options but differ in their use of CPPFLAGS and CFLAGS. The link is done with LDFLAGS_FOR_BUILD. It's hard to tell where the DD64 is coming from, since it doesn't get added by anything in the bash configure scripts, but I suspect it gets put into LOCAL_DEFS somehow. +DD64 is from CFLAGS in the environment prior to configuration. Broadly speaking, linking needs to be done with CFLAGS + LDFLAGS (not just LDFLAGS) precisely because of flags like this. This is already how Automake does things; the bug comes down to bash's build system not following existing convention. It's not reasonable to have to duplicate CFLAGS in LDFLAGS to avoid the reported link error. --Daniel -- NAME = Daniel Richard G. _\|/_Remember, skunks MAIL = sk...@iskunk.org (/o|o\) _- don't smell bad--- MAIL+= sk...@alum.mit.edu(^), it's the people who WWW = (not there yet!) / \ annoy us that do!
Error building mkbuiltins on ia64-hp-hpux11.23
Building bash 4.2 on an HP-UX/Itanium system:
gmake[1]: Entering directory `/tmp/bash-4.2.build/builtins'
rm -f mkbuiltins.o
cc -c -DHAVE_CONFIG_H -DSHELL -I. -I.. -I/tg/freeport/src/bash/bash--4.2
-I/tg/freeport/src/bash/bash--4.2/include -I/tg/freeport/src/bash/bash--4.2/lib
-I/tg/freeport/src/bash/bash--4.2/builtins -DHPUX -D_HPUX_API_LEVEL=20040821
-D_HPUX_SOURCE -g /tg/freeport/src/bash/bash--4.2/builtins/mkbuiltins.c
cc +DD64 +DO11.00 +DSblended +Olit=all -mt +w -z +p -Wl,+k +O1 +Onofltacc
+Onolimit +Onosize -g -o mkbuiltins mkbuiltins.o -ldl
ld: Can't find library or mismatched ABI for -ldl
Fatal error.
gmake[1]: *** [mkbuiltins] Error 1
gmake[1]: Leaving directory `/tmp/bash-4.2.build/builtins'
gmake: *** [builtins/builtext.h] Error 1
The attached patch (against the 4.2 source) fixes the problem for me.
--Daniel
--
NAME = Daniel Richard G. _\|/_Remember, skunks
MAIL = sk...@iskunk.org (/o|o\) _- don't smell bad---
MAIL+= sk...@alum.mit.edu(^), it's the people who
WWW = (not there yet!) / \ annoy us that do!
diff -ru bash-4.2/builtins/Makefile.in bash--4.2/builtins/Makefile.in
--- bash-4.2/builtins/Makefile.in 2010-12-21 08:37:18.0 -0500
+++ bash--4.2/builtins/Makefile.in 2011-04-20 10:51:16.0 -0400
@@ -56,7 +56,7 @@
PROFILE_FLAGS = @PROFILE_FLAGS@
CFLAGS = @CFLAGS@
-CFLAGS_FOR_BUILD = @CFLAGS_FOR_BUILD@ @CROSS_COMPILE@
+CFLAGS_FOR_BUILD = @CFLAGS_FOR_BUILD@ @CROSS_COMPILE@ $(CFLAGS)
CPPFLAGS = @CPPFLAGS@
CPPFLAGS_FOR_BUILD = @CPPFLAGS_FOR_BUILD@
LOCAL_CFLAGS = @LOCAL_CFLAGS@ ${DEBUG}
Encoding oddity
Hi! OS X 10.6.x I am trying to loop over some files with extended characters. Everything works fine if I hardcode the path, see example 1, but if I use a for loop with a * wildcard, I get some problems, see example 2. The problems seems to be that the extended character -- é -- in the hardcoded path, gets translated to the html equivalent of #xE9, whereas the for loop with the wildcard, variable $b in the second example, translates the -- é -- to the html equivalent of #x301. Due to this, [[ $b == $myfile ]] is never true in the second example, even though it would be expected based on what I actually check for. Does anyone have any solution to this problem? Thanks! -- #!/bin/bash touch /Users/myuser/pretérito.txt # Example 1 myfile=/Users/myuser/pretérito.txt for b in $myfile; do if [[ $b == $myfile ]]; then echo OK 1: $b -- $myfile fi done # Example 2 myfolder=/Users/myuser/ unset b for b in $myfolder*; do if [[ $b == $myfile ]]; then echo OK 2: $b -- $myfile fi done - Richard Taubo
Re: filename pattern case-insensitive, but why?
Mike Stroyan wrote:
On Tue, Sep 22, 2009 at 02:36:30AM -0700, thahn01 wrote:
Hello, If I try something like:
$ touch a.c b.c A.c
$ ls [a-z]*.c
a.c A.c b.c
then I get A.c in the output, even if no capital letters are to be found.
The [a-z] range expression matches characters between a and z in the
current locale's collation order. The collation order for en_US.UTF-8 and
other locales has uppercase and lowercase alphabetic characters together.
So in those locales your range includes 'a' through 'z' and 'A' through
'Y'. You can change the locale to C or POSIX to get plain ascii
collation order. You can see the collation order using the sort command.
for c in {32..126}; do eval printf '%c - %d\n' $(printf $'%o' $c)
$c;done | sort -k 1.1,1.1
for c in {32..126}; do eval printf '%c - %d\n' $(printf $'%o' $c)
$c;done | LANG=C sort -k 1.1,1.1
The collation order lists 'a' before 'A', but actually lets a later
character break a tie between otherwise equal uppercase and lowercase
characters. Sort will arrange 'a1', 'A1', 'a2', and 'A2' with the '1'
vs. '2' characters acting as a tiebreaker.
...and that it is why instead of using
$ ls [a-z]*.c
you should use
$ ls [[:lower:]]*.c
idea: statically-linked busy-bash
Dear All, Here's an idea that occurred to me. I'm not sure whether it's a great idea, or a really really stupid one, so please feel free to shoot it down. Anyway, there are an awful lot of shell scripts where a huge number of the coreutils get repeatedly called in separate processes. This call-overhead makes the scripts run noticeably slower. What I'm suggesting is to experimentally build a version of bash which has mv/cp/ls/stat/grep/ all built in. This would be a rather bigger binary, (similar to busybox), but might allow much much faster execution of long scripts. A very quick experiment shows that this might be worthwhile: date; for ((i=0;i100;i++)); do echo -n ; done; date; for ((i=0;i1;i++)); do /bin/echo -n ; done; date Prints: Thu Apr 9 07:05:19 BST 2009 Thu Apr 9 07:05:30 BST 2009 Thu Apr 9 07:05:47 BST 2009 In other words, 1E6 invocations of the builtin takes about 11 seconds, while 1E4 invocations of the standalone binary takes 17 seconds. The builtin echo is therefore about 150 times faster. What do you think? Richard
Re: idea: statically-linked busy-bash
Andreas Schwab wrote: What I'm suggesting is to experimentally build a version of bash which has mv/cp/ls/stat/grep/ all built in. This is possible without rebuilding bash, see the documentation of the `enable' builtin. There are already a few examples in the bash distribution under examples/loadables. Thanks - that's interesting to know. However, most of the examples seem to be cut-down functions in some way - I can see that becoming incompatible/non-portable. What I was contemplating is to build in most of the actual gnu utils with the aim of making eg the builtin grep functionally identical to /bin/grep. Then I could make a system-wide change, replacing the regular bash shell with the fat-bash, and still have everything work... Richard
Re: Bash 4.0.0 crash on completion
André Johansen wrote: Description: When using tab-completion, Bash crashes. I'm using the bash_completion package from http://www.caliban.org/bash/index.shtml#completion. ... Repeat-By: Press tab to get a completion; if Bash enters a programmed completion (i.e. not a simple file name or variable name expansion), Bash crashes. Apply the patches (ftp://ftp.gnu.org/pub/gnu/bash/bash-4.0-patches/ ). I believe this was fixed by patch 002. -- View this message in context: http://www.nabble.com/Bash-4.0.0-crash-on-completion-tp22783625p22784131.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: Completion crashes the shell
Chris F.A. Johnson-3 wrote:
This completion function worked in previous versions, but fails in
bash4.0 when I press TAB:
_cpsh() {
COMPREPLY=( `
cd $HOME/scripts || return 3
printf %s\n ${COMP_WORDS[$COMP_CWORD]}*-sh`
)
COMPREPLY=( ${comprep...@]%-sh} )
}
complete -F _cpsh cpsh
This is what happens:
$ cpsh TAB
malloc: ./parse.y:5563: assertion botched
free: called with unallocated block argument
last command: _cpsh() {
COMPREPLY=( `
cd $HOME/scripts || return 3
printf %s\n ${COMP_WORDS[$COMP_CWORD]}*-sh`
)
COMPREPLY=( ${comprep...@]%-sh} )
}
Aborting...Aborted
Have you applied the tab completion patch that Chet provided here:
http://lists.gnu.org/archive/html/bug-bash/2009-02/msg00153.html
http://lists.gnu.org/archive/html/bug-bash/2009-02/msg00153.html
--
View this message in context:
http://www.nabble.com/Completion-crashes-the-shell-tp22294334p22294834.html
Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: Problem with function cd in bash 4.0
Chet Ramey wrote: Interesting. This happens only on Linux. FreeBSD, MacOS X, and Solaris all interrupt and return to $PS1. Chet Actually, this was happening for me on Solaris too, so looks like not just a Linux thing. But your patch fixed the issue on Solaris as well. Richard -- View this message in context: http://www.nabble.com/Problem-with-function-cd-in-bash-4.0-tp22171999p0451.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Bash RFE: Goto (especially for jumping while debugging)
Dear All, Here's a rather controversial request, namely that bash should support 'goto'. The reason I'd like to see it is to make debugging long scripts easier. I'm working at the moment on a 2000+ line script, and if I want to test stuff at the end, I'd really like to have something like the following: --- #!/bin/bash #initialisation stuff goes here. goto LABEL #lots of stuff here that I want to skip. #Bash doesn't have a multi-line comment feature. #Even if it did, one can't do a multi-line comment containing #another multi-line comment. A good editor makes this less #painful, but isn't an ideal solution. LABEL #stuff I want to test exit #stuff at the end of the script, which I don't want to run while testing. -- We already have exit, which is really short for jump directly to the end. What would be great is a way to jump into the middle. What do you think? Richard P.S. I am sure lots of people will complain (correctly) that Goto is considered harmful. I'd agree that, in most cases, it is. But in some cases, such as the above, it's quite useful. Maybe the feature could be called debug-goto in order to emphasise its debugging nature, as opposed to use in a regular program. P.P.S. a hack that would demonstrate what I mean could be implemented by abusing heredocs. Instead of goto LABEL .. LABEL write cat /dev/null 'label_foo' ... LABEL This has exactly the same effect.
Bash: proposal for operator
Dear All, Might I propose bash should add another operator,for redirection into a variable. This would be by analogy with the operator. For example, we can currently use to save an echo, by doing this: TEXT=Hello World grep -o 'hello' $TEXT instead of TEXT=Hello World echo $TEXT | grep -o 'hello' I am therefore proposing that the following syntax would be useful: echo Hello World TEXT creates a variable named TEXT, whose contents is the string Hello. Why is this useful? 1. Read has a nasty habit of creating subshells. For example, echo Hello | read TEXT doesn't do what we expect. TEXT is empty! 2. The $() or `` constructs are great, excepting that they also create subshells. This messes up things like PIPESTATUS. For example: echo hello | cat | cat | cat #hello echo [EMAIL PROTECTED] #0 0 0 0 TEXT=$(echo hello | cat | cat | cat ) echo [EMAIL PROTECTED] #0 Here we've captured the output we wanted, but lost the pipestatus. 3. The $() construct doesn't let you capture both stderr and stdout into different variables. I know I could do it all with tempfiles, but that somewhat misses the point. Incidentally, if this is useful, it would be nice to support the rather prettier counterpart to the operator, and permit this usage: $TEXT grep -o 'hello' What do you think? Regards, Richard
bash: request for a way to return variables to the parent of a subshell
At the moment, variables set within a subshell can never be accessed by the parent script. This is true, even for an implicit subshell such as caused by read. For example, consider the following (slightly contrived example) touch example-file ls -l | while read LINE ; do if [[ $LINE =~ example-file ]]; then MATCH=true; [a] echo Match-1 fi ; done if [ $MATCH == true ] ;then [b] echo Match-2 fi --- This prints Match-1, but does not print Match-2. The only way to get data out of the read-subshell is by something like exit 2, and looking at $? It's already possible to export a variable into the environment, and for subshells to inherit variables from the main script. Do we need a new keyword to achieve the reverse? Is there any way to make sure that variables defined at [a] can be made to still exist at [b] ? Thanks, Richard
Re: bash: request for a way to return variables to the parent of a subshell
Dear Eric,
Thank you for your helpful answer. I'd understood that bash *doesn't*
pass info back from the child to the parent, but I didn't realise that
it was fundamentally *impossible* to do in Unix. I guess that tempfiles
would do it - though that's rather ugly.
Is there any way to use read to iterate over its standard input
without creating a subshell? If it's of interest, the actual part of
the script I use is below - the aim is to parse the output of ffmpeg
-formats to see whether certain codecs are supported by that build.
Regards,
Richard
--
#Does this version of FFMPEG support the relevant file format? Exit
#if not. Arguments: $1='file' or 'codec'; $2='E','encode' or
# 'D','decode', $3=format/codec_name
#Example:check_ffmpeg_format file D ogg
#The output of `ffmpeg -formats` has section headings such as
#File formats, and each section is delimited by a blank line.
#The first part of the line contains letters DEA(etc) depending
#on whether the codec/file is supported
#for reading (decoding) and/or writing (encoding).
function check_ffmpeg_format_support(){ .
local filecodec=$1
local decodeencode=$2
local filecodec_name=$3
if [ $filecodec == 'file' ];then
local start_trigger='File formats:'
local end_trigger=''
local terminator='\ +'
local filecodec_txt='file format'
else
local start_trigger='Codecs:'
local end_trigger=''
local terminator='$'
local filecodec_txt='with codec'
fi
if [ $decodeencode == 'decode' -o $decodeencode == 'D' ];then
local decodeencode='D[A-Z ]*'
local decodeencode_txt='decoding'
else
local decodeencode='[A-Z ]?E[A-Z ]*'
local decodeencode_txt='encoding'
fi
local matchme='^\ *'$decodeencode'\ +'$filecodec_name'\ *'$terminator
local relevant=false
#Warning: this pipe has the effect of a subshell. Variables are
#set inside the pipeline, and cannot be accessed outside it.
#Search between trigger points.
ffmpeg -formats 2/dev/null | while read line ; do
if [[ $line =~ $start_trigger ]]; then
relevant=true
fi
if [[ $line == $end_trigger ]]; then
relevant=false
fi
if [ $relevant == true ];then
if [[ $line =~ $matchme ]];then #Regex match.
exit 2
fi
#Exit the '| while read...' part, and return $? so we
#know the result.
fi
done
if [ $? != 2 ]; then
echo -e ERROR: the installed version of 'ffmpeg' was built
without support enabled for $decodeencode_txt $filecodec_txt
'$filecodec_name'.\n
exit 1
fi
}
--
Eric Blake wrote:
According to Richard Neill on 7/22/2008 8:04 PM:
| This prints Match-1, but does not print Match-2.
|
| The only way to get data out of the read-subshell is by something like
| exit 2, and looking at $?
You can also use files. The position within a seekable file is preserved
from child to parent, but once you are using files, you might as well go
with the file contents.
| It's already possible to export a variable into the environment, and for
| subshells to inherit variables from the main script. Do we need a new
| keyword to achieve the reverse? Is there any way to make sure that
| variables defined at [a] can be made to still exist at [b] ?
A new keyword is insufficient. This is something that is fundamentally
not provided by Unix systems - short of using the file system, there
really isn't a way to pass arbitrary information from a child process back
to the parent.
But maybe the 'source' builtin is what you are looking for, to execute a
script in the same context rather than forking off a child.
Re: bash: request for a way to return variables to the parent of a subshell
Thank you. That's a really neat solution - and it would never have occurred to me. I always think from left to right! Richard Paul Jarc wrote: Richard Neill [EMAIL PROTECTED] wrote: the aim is to parse the output of ffmpeg -formats to see whether certain codecs are supported by that build. I'd use something like: while read line; do ... done (ffmpeg -formats 2/dev/null) That puts ffmpeg into a subshell instead of read. paul
Bash/readline enhancement: wish to pre-set initial value of input text
Dear All, When using read, it would be really neat to be able to pre-fill the form with a default (or previous) value. For example, a script which wants you to enter your name, and thinks that my name is Richard, but that I might want to correct it. Alternatively, this would be useful within a loop, to allow correction of previously-entered text, without fully typing it again. So, I propose an extra option, -i, to read, which will set the initial value of the text following the prompt. For example, #!/bin/bash read -e -p 'Enter your name: ' -i 'Richard' NAME echo Hello, $NAME This would print: Enter your name: Richard I would then be able to edit the part after the prompt, and change it to: Enter your name: R. Neill This would then print: Hello, R. Neill It is equivalent to the following in PHP/HTML: ? $name='Richard'; ? Enter your name: INPUT TYPE=text NAME=name SIZE=30 VALUE=?=$name;? An alternative syntax might be to make use of stdin for the read command, eg: echo 'Richard' | read -e -p 'Enter your name: ' NAME though I think I prefer the -i. I hope you like this idea. Thanks very much for your help. Richard
Bash substrings: wish for support for negative length (read till n from end)
Dear All,
Substrings in bash contain 2 parameters, the start and the length.
Start may be negative, but if length is negative, it throws an error.
My request is that bash should understand negative length. This would be
useful in some occasions, and would be similar to the way PHP does it:
http://uk.php.net/manual/en/function.substr.php
For clarity, here are all the cases; the relevant ones are the last two:
$ stringZ=abcdef
$ echo ${stringZ:2} #Positive start, no length
cdef#Reads from start.
$ echo ${stringZ: -2} #Negative start, no length
ef #Reads 2 back from end.
$ echo ${stringZ:-2}#No space before the -
abcdef #Is this what we expect?
#(or an unrelated bug?)
$ echo ${stringZ:2:1} #Starts at 2, reads 1 char.
c
$ echo ${stringZ:2: -1} #Wish: start at 2, read till
ERROR #1 before the end. i.e.
# cde
$ echo ${stringZ: -3: -1} #Wish: start 3 back, read till
ERROR #1 before the end. i.e.
# de
i.e. ${string:x:y}
* returns the string, from start position x for y characters.
* but, if x is negative, start from the right hand side
* if y is negative, print up to (the end - y)
Thanks very much,
Richard
Re: Bash substrings: wish for support for negative length (read till n from end)
Jan Schampera wrote:
Richard Neill wrote:
$ echo ${stringZ:2: -1} #Wish: start at 2, read till
ERROR#1 before the end. i.e.
# cde
$ echo ${stringZ: -3: -1}#Wish: start 3 back, read till
ERROR#1 before the end. i.e.
Use (-1), i.e.
$ echo ${stringZ:2:(-1)}
See also
http://bash-hackers.org/wiki/doku.php/syntax/pe#substring_expansion (at
bottom of the section).
Dear Jan,
Thanks for your comment. I now understand why
echo ${stringZ:-1} is invalid, and it has to be
echo ${stringZ:(-1)} or echo ${stringZ: -1}
BUT, the example that you gave doesn't actually work; it returns with
an error:
-bash: (-1): substring expression 0
My point is that, though the first parameter (offset) may be negative,
the second parameter (length) can only be positive. This is what would
be useful to change.
Thanks,
Richard
Bash error message for unterminated heredoc is unhelpful.
Dear All,
In some cases, bash gives exceptionally unhelpful error messages, of the
sort Unexpected end of file. This is next-to-useless as a debugging
aid, since there is no way to find out where the error really lies.
I'm using bash version: bash-3.2-7mdv2008.1
Here are 2 shell scripts with examples.
bug-example.sh demonstrates the problem.
bug-example2.sh is where bash gets it right.
Thanks very much,
Richard
[EMAIL PROTECTED] ~]$ cat bug-example.sh
-
#!/bin/bash
#This is an example of bash being unhelpful with syntax errors.
function usage () {
cat -EOT
This help text is a heredoc
EOT
#NOTE that the line above contains a trailing TAB, and
# is therefore NOT valid as the end of the heredoc.
}
usage
echo A long script goes here...
echo Many lines later...
exit 0
#This script generates the following error:
# ./bug-example.sh: line 37: syntax error: unexpected end of file
#That is really not helpful, since there's no way to track down where
#the error started. Line 37 is not interesting. What we need is a
#warning about line 6.
#At a minimum, we should get this error message:
# ./bug-example.sh: line 37: syntax error: unexpected end of file
# (started at line 6)
#Better, would be this error message:
# ./bug-example.sh: line 6: syntax error: unterminated heredoc.
#An additional buglet is that in fact, trailing whitespace after
#a heredoc terminator should probably be ignored anyway?
-
[EMAIL PROTECTED] ~]$ cat bug-example2.sh
-
#!/bin/bash
#This is an example of bash being *helpful* with syntax errors.
X=$((1 + 2) #NOTE missing trailing ).
echo X is $X #Should print 'X is 3'
echo A long script goes here...
echo Many lines later...
exit 0
#This script gets it right with the error message.
# ./bug-example2.sh: line 5: unexpected EOF while looking for
# matching `)'
# ./bug-example2.sh: line 20: syntax error: unexpected end of file
#So, we can quickly find the bug.
-
Re: Bash error message for unterminated heredoc is unhelpful.
Chet Ramey wrote:
Richard Neill wrote:
Dear All,
In some cases, bash gives exceptionally unhelpful error messages, of the
sort Unexpected end of file. This is next-to-useless as a debugging
aid, since there is no way to find out where the error really lies.
For better or worse, bash allows end-of-file to delimit a here document.
That is historical sh behavior.
The end-of-file syntax error message comes when the shell tries to read
the token following the here document.
Chet
Thanks for your reply.
Fair point. But nevertheless, couldn't bash still tell us why the EOF is
unexpected, and where the _start_ of the offending syntax lies?
That was the point of my second example: the error is still an
unexpected EOF, but in that case, bash also informs the user that the
missing ')' is due to a '(' which was on line 5.
Also, bash should tell us *why* the end-of-file is unexpected...
Incidentally, bash is similarly unhelpful in the case of an 'if'
statement which is missing its 'fi', or a case missing its esac.
If the script is a long one, there's no easy way to locate the offending
token, short of laboriously commenting out sections and doing the
divide-and-conquer method.
Regards,
Richard
Re: Bash arithmetic doesn't give error message on wrap.
Bob Proulx wrote: Richard Neill wrote: b)Consistent with other cases, where bash does give warnings. For example: $ X=$((3+078)) bash: 3+078: value too great for base (error token is 078) $ echo $? 1 That is not really a comparable case. The problem there is that the leading zero specifies an octal constant and the 8 cannot be converted to octal. The 3+ part is just a distraction. echo $((08)) bash: 08: value too great for base (error token is 08) Bob Are you sure this isn't comparable? After all, in both cases, the user has submitted something to which bash cannot give a sensible answer. In the integer-overflow case, bash simply returns the wrong answer, with no warning. But in the octal case, bash (quite correctly, and helpfully) prints a warning. If bash were to be consistent, then it should display no error message in the case of $((3+078)); it should either Do what I mean [evaluate 3 + 078 as 0103, treating 78 as 7 *8 + 8], or Do something daft [eg evaluate as 073 (treating 8 as an integer-overflow in the units place, which is not checked for)] There's obviously an advantage to the user in being warned when an integer overflow occurs; is there any possible downside (apart from a couple of extra lines of code? Richard ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash arithmetic doesn't give error message on wrap.
Chet Ramey wrote: Description: $ echo $((40*40) -2446744073709551616 Repeat-By: Do some arithmetic in bash $(()). If the numbers are out of range, the output will be wrong in all sorts of interesting ways. No error message is given. Fix: Arbitrary-precision maths would be nice. But at least, could we have an error message if an overflow occurs? The man page says: Evaluation is done in fixed-width integers with no check for overflow... but I'd suggest this represents a bug, not a feature. I'm comfortable with the current behavior. POSIX requires that expressions be evaluated according to the C standard, and that standard leaves the treatment of integer overflow as undefined. If POSIX says the behaviour is undefined, then surely bash can do whatever it wants. So, printing an error message would be allowed. The error message would be: a)Most helpful to the user (least surprise) b)Consistent with other cases, where bash does give warnings. For example: $ X=$((3+078)) bash: 3+078: value too great for base (error token is 078) $ echo $? 1 Regards, Richard ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Bash arithmetic doesn't give error message on wrap.
Bash Version: 3.2 Patch Level: 13 Release Status: release Description: $ echo $((40*40) -2446744073709551616 Repeat-By: Do some arithmetic in bash $(()). If the numbers are out of range, the output will be wrong in all sorts of interesting ways. No error message is given. Fix: Arbitrary-precision maths would be nice. But at least, could we have an error message if an overflow occurs? The man page says: Evaluation is done in fixed-width integers with no check for overflow... but I'd suggest this represents a bug, not a feature. Regards, Richard ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: while read subcommand problem
Paul Jarc wrote:
Can you explain what was unsatisfactory about the alternatives given
in the FAQ, so we have a better idea of what would be acceptable?
Here's one possibility:
... | { while ...; do var=...; done; use $var; }
Thanks for the reply, and a possible solution.
The examples in the FAQ do work for the their examples, but I can't figure
out a clean way to implement it with a while loop when reading in lines from
the output of a piped command(s).
Your solution also works, but would be very messy if I wanted to use $var
much later in the script as I would need the rest of the script kept in the
{ }.
I suppose, after years of using the ksh I'm missing the (in my opinion) the
clearer 'command | while read' solution.
--
View this message in context:
http://www.nabble.com/while-read-subcommand-problem-tf3332952.html#a9273080
Sent from the Gnu - Bash mailing list archive at Nabble.com.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: while read subcommand problem
Thank you Paul, Andreas and Kevin. Both the here document solution and the Process substitution solution both work well. I haven't had a good look to see the subtle differences between the two yet. Thank you again. -- View this message in context: http://www.nabble.com/while-read-subcommand-problem-tf3332952.html#a9274702 Sent from the Gnu - Bash mailing list archive at Nabble.com. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Open file descriptors
Other than lsof is there a way to determine what file descriptors are open? Thanks Richard ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash - various feature requests
Dear Grzegorz,
Thanks for your helpful reply.
Grzegorz Adam Hankiewicz wrote:
On 2006-12-27, Richard Neill [EMAIL PROTECTED] wrote:
1)substr support for a negative length argument.
For example,
stringZ=abcdef
echo ${stringZ:2:-1} #prints cde
i.e. ${string:x:y}
returns the string, from start position x for y characters.
but, if x is negative, start from the right hand side
and if y is negative, print up to the end, -y.
This would work the same way as PHP, and be extremely useful for, say,
removing an extension from a filename.
If extension removal is all you need, you can already do it.
$ for f in *; do echo $f; done
Makefile.am
Makefile.in
ucl
$ for f in *; do echo ${f%.*}; done
Makefile
Makefile
ucl
I did know about this, but it seems slightly like a sledgehammer on a
nut, using a regexp instead of a substring. Also, this way doesn't allow
you to trim both the start and the end. Lastly, I just think it would be
a really useful (and easy-to-implement, I think) feature, which is
consistent with the use of PHP and perl. At the moment, the first
parameter may be any integer (postive or negative), but the second
parameter can only be positive.
Best wishes,
Richard
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash - various feature requests
5)An enhancement to read/readline, such that one can specify the initial value with which the buffer is filled. Currently, we can do: read -ep 'Enter your name: ' NAME and I might type Richad Neill. #Note the deliberate typo. If the script recognises this as invalid, the best it can do is: echo Name not recognised read -ep 'Re-enter your name: ' NAME and the user must retype it in full. I'd like to propose adding an -i option for initial value: echo Name not recognised read -ep Please correct your name: -i $NAME The shell prints: Please correct your name: Richad Neill where the latter part is now editable. Thus the really nice editing features of readline can be used for updating values already stored in variables. This is extremely useful when the value is quite long. Is this the same as read -ep Please correct your name: $NAME NAME ? No - that isn't what I meant. What I want to do is: 1)Print the text: Please correct your name: without a trailing newline. 2)Create an editable buffer (using readline), which is initialised with the current value of the variable $NAME and printed to screen. 3)The user edits the buffer as desired, and when he presses ENTER, its contents is assigned to the variable NAME. In the example I gave, with my proposed -i option, the script would present the user with this: Please correct your name: Richad Neill * the cursor position starts at the *, but can be moved around anywhere within the . So the typo could be corrected by keying: Alt-B Ctrl-B, Ctrl-B, r, ENTER whereas currently, the user must type in the full string from scratch. Is that clear? Sorry it's hard to explain without a diagram. Richard ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Fwd: Re: Bash-3.1.17 gets lost looking for end of string in certa in contexts
Just curious: why is it that your version displays 6 within parenthesis, whereas mine displays 2? Shame on me. Decided to stop being lazy and get the answer from the source: man bash... ;) Curiosity satistied: please kindly disregard. Richard ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Fwd: Re: Bash-3.1.17 gets lost looking for end of string in certain contexts
Have just read the archives... ;) Forwarding to the list accordingly!
-- Forwarded Message --
Subject: Re: Bash-3.1.17 gets lost looking for end of string in certain
contexts
Date: Wednesday 03 May 2006 22:36
From: Richard [EMAIL PROTECTED]
To: Eric Blake [EMAIL PROTECTED]
As promised, further to my previous message, hereinafter more data on
the
subject.
(beware of line wrapping at 72 chars)
xterm history
[EMAIL PROTECTED] rag]$ ldd '/mnt/STG1/bin/bash'
libdl.so.2 = /mnt/STG1/lib/libdl.so.2 (0x4001a000)
libc.so.6 = /mnt/STG1/lib/libc.so.6 (0x4001e000)
/mnt/STG1/lib/ld-linux.so.2 (0x4000)
[EMAIL PROTECTED] rag]$ '/mnt/STG1/bin/bash' --version
GNU bash, version 3.1.17(2)-release (i686-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
[EMAIL PROTECTED] rag]$ strings -a '/mnt/STG1/bin/bash' | grep GCC | head -n 1
GCC: (GNU) 3.4.6
[EMAIL PROTECTED] rag]$ '/mnt/STG1/lib/libc-2.3.6.so'
GNU C Library stable release version 2.3.6, by Roland McGrath et al.
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.4.6.
Compiled on a Linux 2.6.12 system on 2006-05-01.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
linuxthreads-0.10 by Xavier Leroy
BIND-8.2.3-T5B
libthread_db work sponsored by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
For bug reporting instructions, please see:
http://www.gnu.org/software/libc/bugs.html.
[EMAIL PROTECTED] rag]$ '/mnt/STG1/bin/bash'
[EMAIL PROTECTED] ~]$ echo $BASH_VERSION
3.1.17(2)-release
[EMAIL PROTECTED] ~]$ status=`echo 'beriberi'| { grep -E -e '().*\1'
/dev/null
21 ; echo $?; }` || echo OOPS
[EMAIL PROTECTED] ~]$ echo $status
0
[EMAIL PROTECTED] ~]$ cd /mnt/STG1/opt/sources/grep-2.5.1a/tests
[EMAIL PROTECTED] tests]$ GREP=grep /mnt/STG1/bin/bash spencer1.script
spencer1.script: line 602: unexpected EOF while looking for matching `''
spencer1.script: line 608: syntax error: unexpected end of file
[EMAIL PROTECTED] tests]$
/xterm history
As you can see the bare command does not trigger the error; however the
script for some contextual reason does trigger it.
Just curious: why is it that your version displays 6 within parenthesis,
whereas mine displays 2?
At your disposal for any addtional info you may require.
Richard
---
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Bash-3.1.17 gets lost looking for end of string in certain contexts
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/mnt/STG1/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I/mnt/STG1/opt/sources/bash-3.1
-I/mnt/STG1/opt/sources/bash-3.1/include -I/mnt/STG1/opt/sources/bash-3.1/lib
-O2 -pipe
uname output: Linux lfs1 2.4.26-0 #1 Sun Aug 29 09:59:18 BRT 2004 i686
GenuineIntel unknown GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 3.1
Patch Level: 17
Release Status: release
Description:
Bug uncovered as follows:
Compiling grep-2.5.1a and during its tests, test #121 is not completed
because of following error messages by bash:
spencer1.script: line 602: unexpected EOF while looking for matching `''
spencer1.script: line 608: syntax error: unexpected end of file
The offending lines (602 thru 607) from spencer1.script are:
602 status=`echo 'beriberi'| { ${GREP} -E -e '().*\1' /dev/null 21 ;
echo $?; }`
603 if test $status -ne 0 ; then
604 echo Spencer test \#121 failed
605 failures=1
606 fi
607 exit $failures
FYI: Running same script thru bash-2.05b all tests in script complete
successfully.
Repeat-By:
Run testsuite of grep-2.5.1a with bash-3.1.17, or use above snippet as
reference.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Build problem with Bash-3.0
I have Linux built mostly from source. I upgraded to GLibc-2.3.6 and BinUtils-2.16.1. I am currently using GCC-3.4.4 due to some problems with GCC-4.0.2. I have applied all 16 Bash-3.0 patches. Bash builds fine using shared libraries, but when I tried to upgrade my statically linked shell for the root user I had problems see attached. Any suggestions would be appreciated, or should I file a bug report? -- JRT *** * * * GNU bash, version 3.00.16(6)-release (i586-pc-linux-gnu) * * *** make[1]: Entering directory `/usr/src/bash-3.0/builtins' ./mkbuiltins -externfile builtext.h -structfile builtins.c \ -noproduction -D . ./alias.def ./bind.def ./break.def ./builtin.def ./caller.def ./cd.def ./colon.def ./command.def ./declare.def ./echo.def ./enable.def ./eval.def ./getopts.def ./exec.def ./exit.def ./fc.def ./fg_bg.def ./hash.def ./help.def ./history.def ./jobs.def ./kill.def ./let.def ./read.def ./return.def ./set.def ./setattr.def ./shift.def ./source.def ./suspend.def ./test.def ./times.def ./trap.def ./type.def ./ulimit.def ./umask.def ./wait.def ./reserved.def ./pushd.def ./shopt.def ./printf.def ./complete.def make[1]: Leaving directory `/usr/src/bash-3.0/builtins' rm -f bash /usr/local/bin/gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde -L./lib/malloc -L./lib/sh -static -static -rdynamic -march=k6-3 -mtune=k6-3 -O2 -o bash shell.o eval.o y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o version.o alias.o array.o arrayfunc.o braces.o bracecomp.o bashhist.o bashline.o list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lsh -lreadline -lhistory -ltermcap -lglob -ltilde -lmalloc bashline.o: In function `bash_groupname_completion_function': bashline.c:(.text+0x2822): warning: Using 'getgrent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking bashline.c:(.text+0x281a): warning: Using 'setgrent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking bashline.c:(.text+0x28a7): warning: Using 'endgrent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ./lib/readline/libreadline.a(complete.o): In function `rl_username_completion_function': complete.c:(.text+0x1df2): warning: Using 'getpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ./lib/readline/libreadline.a(tilde.o): In function `tilde_expand_word': tilde.c:(.text+0x1dc): warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking shell.o: In function `get_current_user_info': shell.c:(.text+0x73d): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ./lib/readline/libreadline.a(complete.o): In function `rl_username_completion_function': complete.c:(.text+0x1dea): warning: Using 'setpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking shell.o: In function `get_current_user_info': shell.c:(.text+0x7ee): warning: Using 'endpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ./lib/sh/libsh.a(netopen.o): In function `netopen': netopen.c:(.text+0x87): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking bashline.o: In function `bash_servicename_completion_function': bashline.c:(.text+0x2690): warning: Using 'getservent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking bashline.c:(.text+0x2688): warning: Using 'setservent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking bashline.c:(.text+0x2796): warning: Using 'endservent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/libc.a(malloc.o): In function `free': malloc.c:(.text+0x13a0): multiple definition of `free' ./lib/malloc/libmalloc.a(malloc.o):malloc.c:(.text+0xe00): first defined here /usr/bin/ld: Warning: size of symbol `free' changed from 25 in ./lib/malloc/libmalloc.a(malloc.o)
bash_profile ?
Are there any good bash_profile links, of showing how to create a good simple bash_profile, that would also include $PATH. Thanks - Richard ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
