Invalid array subscript (single backslash) causes assertion failure
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib
-g -O2 -Wall
uname output: Linux redacted 2.6.22-14-generic #1 SMP Tue Feb 12
07:42:25 UTC 2008 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 3.2
Patch Level: 25
Release Status: release
Description:
Bash prints the following lines and dumps core:
malloc: ../bash/arrayfunc.c:616: assertion botched
free: start and end chunk sizes differ
last command: ${foo[\]}
Aborting...Aborted (core dumped)
Repeat-By:
Enter the following line in interactive mode:
${foo[\]}
Fix:
Obviously not a valid construct, but nevertheless shouldn't crash.
Re: Memory leak when catting(/sedding/...) large binary files with backticks
Chet Ramey wrote: [EMAIL PROTECTED] wrote: Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic uname output: Linux pmpc983.npm.ac.uk 2.6.24.4-64.fc8 #1 SMP Sat Mar 29 09:15:49 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 3.2 Patch Level: 33 Release Status: release Description: Using echo `cat ...` on a large binary file causes lots of memory to be used (fine), but if you ctrl-c while it's running it doesn't die properly and doesn't return used memory when finished. Originally found by screwing up a sed command (can also reproduce bug using sed rather than cat) while trying to rename a group of files. Repeat-By: Every time 1. Find large binary data file for test (mine is ~3.2GB) 2. echo `cat filename` 3. Ctrl-C previous command while running (doesn't terminate) 4. When step 2 eventually returns it does not release memory I'm not sure what you mean by `doesn't return used memory', but if you mean a process's size as reported by ps or similar, that does not indicate a memory leak. A memory leak is memory that has been allocated by a program to which it retains no handles. malloc acts as a cache between an application and the kernel. Memory obtained from the kernel using malloc may, under some circumstances, be returned to the kernel upon free, but this may not always be possible. Memory that is not returned to the kernel by freeing pages or using sbrk with a negative argument is retained and used to satisfy future requests. I ran your test using valgrind to check for memory leaks (but with only a 330 MB file), and it reported no leaks after ^C. Chet I was just going on what ps reported, but I assumed it was leaking on the basis that the memory did not report as "free" until I kill -9'd the relevant bash process (just kill didn't work). Once it'd been done a couple of times so most of the memory was consumed, it definitely had an adverse effect on performance - even other simple bash commands took several seconds to return a result, which I assume was because they were fighting for memory. The affected bash also didn't show any sub-processes using ps -auxf (shouldn't it have shown a cat process if it was still holding resources?). If you guys on here reckon it's not a bug that's fine - I admit I'm not exactly au fait with the inner workings of bash, maybe it's working as intended. I just figured since it was eating my memory and not making that memory available to other programs when it was ^C'd (as you would do when you realised you'd inadvertently catted or sedded a 3GB binary file) that I'd report it. Ben
Re: builtin printf not printing unicode characters?
pk wrote: The man page says that bash builtin printf supports the standard printf(1) formats. But it seems that \u is not working: $ /usr/bin/printf '\u212b\n' Å $ printf '\u212b\n' \u212b Am I doing something wrong here? The `\u' format string escape is not standard. I will consider it for a future enhancement. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Re: builtin printf not printing unicode characters?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Chet Ramey on 5/10/2008 8:16 PM: | The `\u' format string escape is not standard. I will consider it for a | future enhancement. You may also be interested in this recent thread on coreutils' printf and \u: http://lists.gnu.org/archive/html/bug-coreutils/2008-05/msg00067.html - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgoO3oACgkQ84KuGfSFAYBDggCgnV33ieJ/+q9Zet7vZ6Q8GJuR oBQAn1efF5bjdfgLYgIM7L2EzgO+Mo9l =NWsX -END PGP SIGNATURE-
Re: spaces in the shebang interpreter path
On Sun, May 11, 2008 at 02:01:29PM -0400, Paul Jarc wrote: > Felix Schwarz <[EMAIL PROTECTED]> wrote: > > I'm not able to specify an interpreter in a shebang line if the path > > to this interpreter contains spaces. > > It's actually the kernel that interprets that line, not bash. The > historical behavior is that space separates the interpreter from an > optional argument, and there is no escape mechanism, so there's no way > to specify an interpreter with a space in the path. It's unlikely > that this would ever change, since that would break existing scripts > that rely on thecurrent behavior. [...] It should also be noted that the #! mechanism is not standard. Read: not supported by either of the POSIX or Unix standard. On POSIX systems, you can still use scripts, but either they are considered as POSIX sh scripts (when they are called via execvp/execlp(3) or sh(1) (and thus system(3)/popen(3)) env/awk/ex/vi... and all the standard utilities that can execute commands) or you have to explicitely call the interpreter (awk -f /path/the/file for instance). Now, depending on the syntax of your interpreter, you could use some trick to have your file interpreted by the proper interpreter within those POSIX constraints. For instance for awk, you could do thinks like: "exec" "awk" "-f" "$0" "$@" && 0 -- Stéphane
PATH value doesn't get updated
I put this in my .bash_profile: PATH=$PATH:/opt/lampp/bin export PATH but when I "echo $PATH" it doesn't include the /opt/lampp/bin. -- View this message in context: http://www.nabble.com/PATH-value-doesn%27t-get-updated-tp17189469p17189469.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: PATH value doesn't get updated
carlwenrich wrote: > I put this in my .bash_profile: > > PATH=$PATH:/opt/lampp/bin > export PATH > > but when I "echo $PATH" it doesn't include the /opt/lampp/bin. The .bash_profile is sourced by bash when it is invoked as an interactive login shell. Therefore you would need to log in after having made that change in order for bash to read the file and the effect to be seen. Did you log in after having made that change? Was bash invoked as an interactive login shell so that it would read that file? echo $0 echo $- Bob
Re: PATH value doesn't get updated
Yes. I (1) made the change to .bash_profile, then (2) restarted the machine, then (3) logged in again. When I echo $PATH the /opt/lampp/bin is not included. Bob Proulx <[EMAIL PROTECTED]> wrote: carlwenrich wrote: > I put this in my .bash_profile: > > PATH=$PATH:/opt/lampp/bin > export PATH > > but when I "echo $PATH" it doesn't include the /opt/lampp/bin. The .bash_profile is sourced by bash when it is invoked as an interactive login shell. Therefore you would need to log in after having made that change in order for bash to read the file and the effect to be seen. Did you log in after having made that change? Was bash invoked as an interactive login shell so that it would read that file? echo $0 echo $- Bob
Re: PATH value doesn't get updated
Carl Wenrich wrote: > Bob Proulx wrote: > > Did you log in after having made that change? Was bash invoked as > > an interactive login shell so that it would read that file? > > > > echo $0 > > echo $- > > Yes. I (1) made the change to .bash_profile, then (2) restarted the > machine, then (3) logged in again. When I echo $PATH the > /opt/lampp/bin is not included. That second question was also very important. Without that information I don't know if I should suggest one action or a different action. Was bash invoked as an interactive login shell so that it would read that file? The way I tell is by running those two commands that I suggested running. What do you get for the following two commands? echo $0 echo $- The $0 is the name used to invoke the shell. If it starts with a '-' then this is used to instruct the shell that it is a login shell. The second variable $- is the flags set to the shell. The 'i' for interactive should be in there. Example: NOT a login shell, will NOT source .bash_profile: $ echo $0 bash $ echo $- himBHP $ Example: Yes, a login shell: $ echo $0 -bash $ echo $- himBHP $ And of course the bash "-l" and "--login" options will override this default behavior. If it is not a login shell then to suggest improvements it would be necessary to know the type of system you are using and how you are logging into it. There are many possibilities and I can't guess which one you might be using. You didn't say in your messages. By the way... It is not necessary to restart your system. That is way too much. Simply log in again to have profile file changes take effect. Bob
Re: PATH value doesn't get updated
echo $0 gives me "bash" echo $- gives me "himBH" Bob Proulx <[EMAIL PROTECTED]> wrote: Carl Wenrich wrote: > Bob Proulx wrote: > > Did you log in after having made that change? Was bash invoked as > > an interactive login shell so that it would read that file? > > > > echo $0 > > echo $- > > Yes. I (1) made the change to .bash_profile, then (2) restarted the > machine, then (3) logged in again. When I echo $PATH the > /opt/lampp/bin is not included. That second question was also very important. Without that information I don't know if I should suggest one action or a different action. Was bash invoked as an interactive login shell so that it would read that file? The way I tell is by running those two commands that I suggested running. What do you get for the following two commands? echo $0 echo $- The $0 is the name used to invoke the shell. If it starts with a '-' then this is used to instruct the shell that it is a login shell. The second variable $- is the flags set to the shell. The 'i' for interactive should be in there. Example: NOT a login shell, will NOT source .bash_profile: $ echo $0 bash $ echo $- himBHP $ Example: Yes, a login shell: $ echo $0 -bash $ echo $- himBHP $ And of course the bash "-l" and "--login" options will override this default behavior. If it is not a login shell then to suggest improvements it would be necessary to know the type of system you are using and how you are logging into it. There are many possibilities and I can't guess which one you might be using. You didn't say in your messages. By the way... It is not necessary to restart your system. That is way too much. Simply log in again to have profile file changes take effect. Bob
Re: PATH value doesn't get updated
Carl Wenrich wrote: > echo $0 gives me "bash" > echo $- gives me "himBH" Then bash hasn't been invoked as a login shell and therefore isn't instructed to source the .bash_profile. > If it is not a login shell then to suggest improvements it would be > necessary to know the type of system you are using and how you are > logging into it. There are many possibilities and I can't guess which > one you might be using. You didn't say in your messages. You have yet to say how are you are logging into your machine. There are many possibilities and without information it is impossible to guess. In the hope that it is helpful I will take a shot in the dark... On my HP-UX machine I log into the text console. This gives me a login shell that sources my .bash_profile. I then start X11 using 'xinit' which inherits all of the exported variables. On my Debian GNU/Linux machine I log in using GDM. Because logging in with XDM, or GDM, or KDM doesn't start a login shell I need to tell it this explicitly. I use an executable ~/.xsession file. In it I explicitly tell bash that it is a login shell which causes my .bash_profile to be sourced. Subsequent shells inherit the environment. This is what I use in my personal configuration: #!/bin/bash --login # exec x-session-manager # exec gnome-session # exec startkde exec fvwm2 Red Hat solves this problem in a better way by invoking the user session as a login shell from the system X start up scripts. By doing it that way the user doesn't need to worry about it. Last time I checked SuSE was a problem because it forced sourcing of the $HOME/.bash_profile (or was it .profile?) regardless of the user shell and then redirected all errors to /dev/null effectively ignoring them. Other systems will be similarly different. In any case I believe you have an answer to your question about why your ~/.bash_profile wasn't being sourced. It wasn't being sourced because your shell isn't invoked as a login shell and therefore shouldn't source it. Good luck! Bob
Re: PATH value doesn't get updated
I just log into the box that appears on the standard ubuntu startup. I enter my username and password, then the desktop comes up. I see now that the .bash_profile isn't being sourced (I thought it was according to what I've been able to pick up on the web). If I source it manually, the $PATH gets updated. Why does ubuntu provide the .bash_profile when a user is created, and then not source it when the system starts up? And since it doesn't, what do I change to make it happen? Bob Proulx <[EMAIL PROTECTED]> wrote: Carl Wenrich wrote: > echo $0 gives me "bash" > echo $- gives me "himBH" Then bash hasn't been invoked as a login shell and therefore isn't instructed to source the .bash_profile. > If it is not a login shell then to suggest improvements it would be > necessary to know the type of system you are using and how you are > logging into it. There are many possibilities and I can't guess which > one you might be using. You didn't say in your messages. You have yet to say how are you are logging into your machine. There are many possibilities and without information it is impossible to guess. In the hope that it is helpful I will take a shot in the dark... On my HP-UX machine I log into the text console. This gives me a login shell that sources my .bash_profile. I then start X11 using 'xinit' which inherits all of the exported variables. On my Debian GNU/Linux machine I log in using GDM. Because logging in with XDM, or GDM, or KDM doesn't start a login shell I need to tell it this explicitly. I use an executable ~/.xsession file. In it I explicitly tell bash that it is a login shell which causes my .bash_profile to be sourced. Subsequent shells inherit the environment. This is what I use in my personal configuration: #!/bin/bash --login # exec x-session-manager # exec gnome-session # exec startkde exec fvwm2 Red Hat solves this problem in a better way by invoking the user session as a login shell from the system X start up scripts. By doing it that way the user doesn't need to worry about it. Last time I checked SuSE was a problem because it forced sourcing of the $HOME/.bash_profile (or was it .profile?) regardless of the user shell and then redirected all errors to /dev/null effectively ignoring them. Other systems will be similarly different. In any case I believe you have an answer to your question about why your ~/.bash_profile wasn't being sourced. It wasn't being sourced because your shell isn't invoked as a login shell and therefore shouldn't source it. Good luck! Bob
