ulimit and -e switch
rom: Frans de Boer To: bug-bash@gnu.org Subject: [ulimit and -e switch] Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -pg -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='l inux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/u sr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux servt1 2.6.19.2-SuSE9.3 #1 PREEMPT Tue Jan 23 00:25:19 CET 2 007 i686 i686 i386 GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 3.2 Patch Level: 9 Release Status: release Description: [Using ulimit -e [-p] ID does not work. If used, the next line is printed: limit: usage: ulimit [-SHacdflmnpstuv] [limit] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash usage w/ssh question (re: suse10.2)
I have an odd usage question which may or may not be within the scope of this list. Background: in installing a system with suse10.2, I noticed my .bashrc effectively getting run twice when I use "ssh" to run a remote command (no interactive login). The seems to be due to a change in SuSE's "/etc/bash.bashrc" doing a bit extra (sourcing /etc/profile) on non-interactive logins as the SuSE way to set system-specific variables. *** The thing is, I'm not sure "who" is calling "/etc/bash.bashrc". Is it part of some standard I am not aware of? It doesn't appear to be called out of any ssh-rc script, so I'm not sure why it is getting run in the first place, but because it is run, it now calls profile which ends up calling my own variable definitions (declared read-only), twice - because my variable defines don't expect to be called from both "/etc/profile" and from "~/.bashrc" in the same session. Another question (maybe a budding RFE?) is: Is there a way to find out (and print the "source stack" -- i.e. nested "calls" using "." to source files that are sourcing more...etc. I know it isn't technically a procedure call, but there is a concept of a call stack in that a sourced file is performed as though inserted in the current routine, then control resumes at the first line after the source. Semantically -- it isn't a "call stack", but more akin to the actions of a "preprocessor", but "syntactically", it functions much like file a calls(sources) b, b calls(sources) c... etc... Thanks, Linda ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash usage w/ssh question (re: suse10.2)
Ah...see /etc/bash.bashrc in the source...just not mentioned in the manpage. Urg. Not to figure out a way around this that isn't too SuSE specific... I take it that /etc/bash.bashrc is supposed to execute once/bash as well as users' /.bashrc? Sigh...am just annoyed that SuSE policy is to screw over users who read the man page and that bash not calling profile on non-interactive logins is "sortof" (in their opinion) a bug...sigh. Linda Walsh wrote: *** The thing is, I'm not sure "who" is calling "/etc/bash.bashrc". Is it part of some standard I am not aware of? ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bush-3.2 regression: breaked colour prompt.
Hello. I use the following colored primary prompt string: PS1="\[\033[01;32m\]\w \$\[\033[00;00m\] " Then I create directory with russian name. (locale ru_RU.UTF8). If I cd into directory in bash-3.1 everything works as expected but in bash-3.2 cursor became positioned N spaces after $ and every typed character depart the previous the same N spaces. Well better to illustrate: In bash-3.1: ~/tmp/bash/bash-3.1 $ mkdir тест ~/tmp/bash/bash-3.1 $ cd тест/ ~/tmp/bash/bash-3.1/тест $ ls ~/tmp/bash/bash-3.1/тест $ # In bash-3.2: ~/tmp/bash/bash-3.2 $ mkdir тест/ ~/tmp/bash/bash-3.2 $ cd тест/ ~/tmp/bash/bash-3.2/тест $ ls ~/tmp/bash/bash-3.2/тест $ # Where # denotes cursor position. You see that 'l' and 's' are separted with 8 spaces and initial cursor position also separated from $ on 8 spaces. BTW. With PS1="\w \$ " everything works but there is no color :) JFYI: 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='/home/peter/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux camobap 2.6.19-gentoo-r5-suspend2 #7 PREEMPT Sun Feb 11 19:07:33 MSK 2007 i686 Intel(R) Pentium(R) M processor 1700MHz GenuineIntel GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 3.2 Patch Level: 0 Release Status: release And please CC me to answers. Thank you. Peter. signature.asc Description: This is a digitally signed message part ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
collect2: ld returned 1 exit status
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: x86_64-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-g$uname output: Linux home 2.6.17-gentoo #9 Fri Dec 22 20:45:00 MSK 2006 x86_64 AMD Athlon(tm) 64 Processor 3700+ AuthenticAM$Machine Type: x86_64-pc-linux-gnu Bash Version: 3.2 Patch Level: 9 Release Status: release make[1]: Leaving directory `/mnt/lfs/static/src/bash-3.2/lib/malloc' rm -f bash gcc -s -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde -L./lib/malloc -L./lib/sh -static -static -rdynamic -g -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 -lcurses -lglob -ltilde -lmalloc bashline.o: In function `bash_groupname_completion_function': /mnt/lfs/static/src/bash-3.2/bashline.c:1818: warning: Using 'getgrent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /mnt/lfs/static/src/bash-3.2/bashline.c:1812: warning: Using 'setgrent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /mnt/lfs/static/src/bash-3.2/bashline.c:1823: 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': /mnt/lfs/static/src/bash-3.2/lib/readline/complete.c:1860: 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:390: 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': /mnt/lfs/static/src/bash-3.2/shell.c:1589: 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': /mnt/lfs/static/src/bash-3.2/lib/readline/complete.c:1852: 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': /mnt/lfs/static/src/bash-3.2/shell.c:1605: 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': /mnt/lfs/static/src/bash-3.2/lib/sh/netopen.c:229: 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': /mnt/lfs/static/src/bash-3.2/bashline.c:1776: warning: Using 'getservent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /mnt/lfs/static/src/bash-3.2/bashline.c:1756: warning: Using 'setservent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /mnt/lfs/static/src/bash-3.2/bashline.c:1781: warning: Using 'endservent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../../lib64/libc.a(malloc.o): In function `free': : multiple definition of `free' ./lib/malloc/libmalloc.a(malloc.o):/mnt/lfs/static/src/bash-3.2/lib/malloc/malloc.c:1270: first defined here /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../../x86_64-pc-linux-gnu/bin/ld: Warning: size of symbol `free' changed from 61 in ./lib/malloc/libmalloc.a(malloc.o) to 154 in /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../../lib64/libc.a(malloc.o) /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../../lib64/libc.a(malloc.o): In function `malloc': : multiple definition of `malloc' ./lib/malloc/libmalloc.a(malloc.o):/mnt/lfs/static/src/bash-3.2/lib/malloc/malloc.c:1255: first defined here /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../../x86_64-pc-linux-gnu/bin/ld: Warning: size of symbol `malloc' changed from 61 in ./lib/malloc/libmalloc.a(malloc.o) to 466 in /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../../lib64/libc.a(malloc.o) /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../../lib64/libc.a(malloc.o):
set -e and OR-lists
Hi, Is the following behaviour intended or a bug in bash (3.1.17(1)-release)? The command list (set -e; false; echo hello) does not print hello and has non-zero exit status. All fine. If I try to use this fact to display an error message the semantics changes. The following command (set -e; false; echo hello) || echo fail _does_ print hello _rather_ than fail. Why is this? One could argue that the first echo command is now part of an OR-list, but this on the parent-shell level (where set -e has no other effects) and via the command list, and not in the subshell. A corresponding change occurs if the command list is part of an AND-list. Please CC this address since I'm not on the list. Thanks, Johan Hovold ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash usage w/ssh question (re: suse10.2)
Linda Walsh wrote: > Ah...see /etc/bash.bashrc in the source...just not mentioned in the > manpage. Urg. > Not to figure out a way around this that isn't too SuSE specific... The use of /etc/bash.bashrc (the name is actually arbitrary) is a configuration option that's disabled by default. Look at the SYS_BASHRC define in config-top.h. SUSE probably enabled it. It's not a standard part of the build, so it's not in the man page. Putting a mention of it in would cause more problems that it would solve. 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/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash usage w/ssh question (re: suse10.2)
Linda Walsh wrote: > Another question (maybe a budding RFE?) is: Is there a way to find > out (and print the "source stack" -- i.e. nested "calls" using > "." to source files that are sourcing more...etc. I know it isn't > technically a procedure call, but there is a concept of a call > stack in that a sourced file is performed as though inserted in > the current routine, then control resumes at the first line after > the source. > Semantically -- it isn't a "call stack", but more akin to the actions > of a "preprocessor", but "syntactically", it functions much like > file a calls(sources) b, b calls(sources) c... etc... Look at the BASH_SOURCE array variable. It was originally added as part of the support for the bash debugger, but it does what you want. 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/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
