[severe] access outside simlinked directory
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 ogro 2.6.27-7-generic #1 SMP Tue Nov 4 19:33:20 UTC 2008 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.2 Patch Level: 39 Release Status: release Description: if you have a simlink pointing to a directory, chdir to that symlink dir, and type something with '..', you access the parent of real directory, not previous simlinked one. it is not supposed to be like, may be dangerous in a shared environment. i tested only (but not limited) with cd, cat, vi, chmod and chown; all returning described results. Repeat-By: :/my/dir1/# ls -F /other/ dir2/ otherfile :/my/dir1/# ln -s /other/dir2/ :/my/dir1/# ls -F dir2@ - /other/dir2/ myfile :/my/dir1/# cd dir2 :/my/dir1/dir2/# ls -F .. dir2/ otherfile Notes: this was copypasted and sended trought hotmail since bashbug didn't connect. i am not a developer, so if this is a dumb report and there is a reason why, please ignore it xD AT-HE _ Access your email online and on the go with Windows Live Hotmail. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_access_112008
Re: envvar's leaking into open()
Chet Ramey wrote: [EMAIL PROTECTED] wrote: hello, i made some observation by chance. bash 3.2 seems to leak environment variables into open() syscalls (older bash 2.0 does not show this behaviour) Bash isn't doing the opens -- they're coming from the libc locale code. Bash isn't doing opens, but do bad setlocale() calling. More info in redhat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=354171
Re: [severe] access outside simlinked directory
AT-HE [EMAIL PROTECTED] wrote: if you have a simlink pointing to a directory, chdir to that symlink dir, and type something with '..', you access the parent of real directory, not previous simlinked one. That's the kernel's doing, not bash's. When interpreting pathnames relative to the current working directory, the kernel only cares about where you are, not how you got there. It's been that way for as long as Unix has had symlinks, and changing it now would break a lot of programs that expect the current behavior. paul
Re: [severe] access outside simlinked directory
AT-HE wrote: if you have a simlink pointing to a directory, chdir to that symlink dir, and type something with '..', you access the parent of real directory, not previous simlinked one. Symlinks violate some principles of least surprise. Therefore it is not surprise that it is impossible to make all uses of symlinks unsurprising. it is not supposed to be like, may be dangerous in a shared environment. What you are describing is actually the way it is supposed to work. Symbolic links were developed in BSD and a wonderful invention they have proved to be. But they are not entirely consistent throughout. They do not change the behavior of the filesystem. They are simply a symbolic name translation for that individual target. Instead of the default bash behavior of tracking the logical path try it with this option set: set -o physical In GNU bash the 'set -o physical' option turns off this logical path tracking of the shell. Setting that option with your example would report the new name of the physical present working directory. That will make what is actually happening much more obvious. What you are seeing with logical path tracking is considered a feature by many. As an old timer I don't like it since it causes confusion. But 99% of everyone I talk with about this prefers the new behavior which creates a facade around symlinks. (New is relative when the behavior has been around as many years as this one.) I originally saw this introduced in ksh, the Korn shell, and bash has followed ksh in this matter. i tested only (but not limited) with cd, cat, vi, chmod and chown; all returning described results. Of the things you tested all but cd are external command unrelated to bash itself. That is almost always a good clue that this isn't something related to the shell. Note that '.' and '..' are real directory entries. They are not pseudo entries as some appear to believe. The shell covers them with fake entires to change the behavior into logical paths when symlinks are in use. But that does not remove the underyling entries. All operating system kernel system calls use the real entries. The fake entries are an imaginary world created within the process model of new-style, symlink-aware command shells. info bash `cd' cd [-LP] [DIRECTORY] Change the current working directory to DIRECTORY. If DIRECTORY is not given, the value of the `HOME' shell variable is used. If the shell variable `CDPATH' exists, it is used as a search path. If DIRECTORY begins with a slash, `CDPATH' is not used. The `-P' option means to not follow symbolic links; symbolic links are followed by default or with the `-L' option. If DIRECTORY is `-', it is equivalent to `$OLDPWD'. The return status is zero if the directory is successfully changed, non-zero otherwise. `pwd' pwd [-LP] Print the current working directory. If the `-P' option is supplied, the path printed will not contain symbolic links. If the `-L' option is supplied, the path printed may contain symbolic links. The return status is zero unless an error is encountered while determining the name of the current directory or an invalid option is supplied. * The Bash `cd' and `pwd' builtins (*note Bourne Shell Builtins::.) each take `-L' and `-P' builtins to switch between logical and physical modes. `set' set [--abefhkmnptuvxBCHP] [-o OPTION] [ARGUMENT ...] `-o OPTION-NAME' `physical' Same as `-P'. `-P' If set, do not follow symbolic links when performing commands such as `cd' which change the current directory. The physical directory is used instead. By default, Bash follows the logical chain of directories when performing commands which change the current directory. For example, if `/usr/sys' is a symbolic link to `/usr/local/sys' then: $ cd /usr/sys; echo $PWD /usr/sys $ cd ..; pwd /usr If `set -P' is on, then: $ cd /usr/sys; echo $PWD /usr/local/sys $ cd ..; pwd /usr/local Try setting either 'set -o physical' or equivalently 'set -P' in your $HOME/.bashrc file and you will always follow the physical path. Hope this helps, Bob
Re: C-z bg without the lurch
[EMAIL PROTECTED] wrote: Anyway, I wish there was a way to communicate a disown command or something to that shell. stty -a shows a lot of weird keys. Anyway, it would be neat if there was a key e.g., C-y, that would have the effect of C-z bg, but without ever letting the job in question feel the brief sting of being stopped. Anyway, how could it be that the mighty bash can't let me get back to my emacs without lurching my CD burning job, even for a split second? Since the cd burning job is the current foreground process and has the keyboard, there's not going to be a way to do that without getting it involved in some way. The current kernel mechanism for doing this requires signals, so there's also going to be some signal sent to return control to bash. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
document -u $@ $* special case
Gentlemen, I have discovered a documentation oversight. In the manual,
we see:
-u Treat unset variables as an error when performing param-
eter expansion. If expansion is attempted on an unset
variable, the shell prints an error message, and, if not
interactive, exits with a non-zero status.
and
${parameter:?word}
Display Error if Null or Unset. If parameter is null or unset,
the expansion of word (or a message to that effect if word is
not present) is written to the standard error and the shell, if
it is not interactive, exits. Otherwise, the value of parameter
is substituted.
However, different behavior is observed between
set -u --
: $@ $*
: $1
and
set --
: ${*?} [EMAIL PROTECTED]
: ${1?}
Therefore the -u paragraph needs to add that $@ and $* unset are not
caught by -u, but $1, $2... are.
Re: document -u $@ $* special case
[EMAIL PROTECTED] wrote: Gentlemen, I have discovered a documentation oversight. In the manual, we see: You've discovered a bug. They should be treated the same way. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/
Possible bug with respect to global variable within block of code when piping the output of later
Hi
I stumbled over that variables defined outside of blocks of code do
not get altered by assignment statements to that variable within the
block when the output of the block is piped to some other process.
Re-direction of the block output to a file or no re-direction changes
the outer variable. It seems to me inconsistent behavior and might be
regarded as bug. Maybe the piping converts the block implicitly to a
subshell. Please find below a demo script.
Version of my bash:
GNU bash, version 3.00.16(1)-release (sparc-sun-solaris2.10)
Copyright (C) 2004 Free Software Foundation, Inc.
#!/bin/bash
# Block changes outer variable
_TEST_VARIABLE=5
echo _TEST_VARIABLE out of block: ${_TEST_VARIABLE} # 5
{
echo _TEST_VARIABLE in block: ${_TEST_VARIABLE} # 5
_TEST_VARIABLE=asedfawsed
echo _TEST_VARIABLE in block: ${_TEST_VARIABLE} # asedfawsed
}
echo _TEST_VARIABLE out of block: ${_TEST_VARIABLE} # asedfawsed
echo
# Block does not change outer variable when output piped
_TEST_VARIABLE=5
echo _TEST_VARIABLE out of block: ${_TEST_VARIABLE} # 5
{
echo _TEST_VARIABLE in block: ${_TEST_VARIABLE} # 5
_TEST_VARIABLE=asedfawsed
echo _TEST_VARIABLE in block: ${_TEST_VARIABLE} # asedfawsed
} | grep -E .
echo _TEST_VARIABLE out of block: ${_TEST_VARIABLE} # 5
echo
# Block changes outer variable when output piped
_TEST_VARIABLE=5
echo _TEST_VARIABLE out of block: ${_TEST_VARIABLE} # 5
{
echo _TEST_VARIABLE in block: ${_TEST_VARIABLE} # 5
_TEST_VARIABLE=asedfawsed
echo _TEST_VARIABLE in block: ${_TEST_VARIABLE} # asedfawsed
} tmp.txt
cat tmp.txt
echo _TEST_VARIABLE out of block: ${_TEST_VARIABLE} # asedfawsed
exit 0
Cheers
Thiemo
Re: Possible bug with respect to global variable within block of code when piping the output of later
Thiemo Kellner [EMAIL PROTECTED] wrote: Maybe the piping converts the block implicitly to a subshell. Yes, it does. This is documented in the man page, under Pipelines in the SHELL GRAMMAR section, and in the FAQ, entry E4. paul
