Doh - slow brain day - thanks for the correction. That nullifies my
concern when user is not root, for part of the rename() issue.
I think the return values of rename() should be checked, and it
history_do_write() should not try to rename(bakname, output) unless it
actually did rename(output, bak
Jonathan Hankins writes:
> Aside from the case where the user running bash is root, I think it's not
> uncommon for users to have group write access to a variety of things in
> /dev.
Rename or delete requires write access to the containing directory.
Andreas.
--
Andreas Schwab, sch...@linux-m
A test with the POSIX S_ISREG macro on HISTFILE will determine if it, or
the file it points to in the case of a symlink, is a regular file.
Just looked through the source, and it looks like general.c:file_exists()
does not do any special handling of non-regular files, and
lib/readline/histfile.c:h
I agree about being able to use named pipes, etc. as HISTFILE. My concern
is that I think there may be a code path that leads to rename() and
open(O_TRUNC...) being called on something that isn't a regular file.
Furthermore, I think that if someone can manipulate a user's HISTFILE
setting maliciou
On 1/30/15 2:09 PM, Jonathan Hankins wrote:
> A test with the POSIX S_ISREG macro on HISTFILE will determine if it, or
> the file it points to in the case of a symlink, is a regular file.
>
> Just looked through the source, and it looks like general.c:file_exists()
> does not do any special handli
On 1/30/15 1:51 AM, Chih-Chieh Chou wrote:
> # trap 'echo cmd=$BASH_COMMAND' DEBUG
> # trap 'echo Ctrl-C pressed' SIGINT
> cmd=trap 'echo Ctrl-C pressed' SIGINT
You don't say anything about what version of bash you're using or what
system you're running it on, but I could not reproduce this using
On Fri, Jan 30, 2015 at 09:58:43AM -0500, Chet Ramey wrote:
> On 1/30/15 4:36 AM, crocket wrote:
> > It turns out that tramp on emacs 24.4 sets $HISTFILE to /dev/null and
> > makes bash delete /dev/null when I kill emacs.
> >
> > When /dev/null is not a character device but a regular file, a lot o
On 1/30/15 4:36 AM, crocket wrote:
> It turns out that tramp on emacs 24.4 sets $HISTFILE to /dev/null and
> makes bash delete /dev/null when I kill emacs.
>
> When /dev/null is not a character device but a regular file, a lot of
> programs freeze.
This indicates a permissions or file system prob
It turns out that tramp on emacs 24.4 sets $HISTFILE to /dev/null and
makes bash delete /dev/null when I kill emacs.
When /dev/null is not a character device but a regular file, a lot of
programs freeze.
I think a program should deal with weird inputs gracefully especially
when it's not obvious t
It turns out that tramp on emacs 24.4 sets $HISTFILE to /dev/null and
makes bash delete /dev/null when I kill emacs.
When /dev/null is not a character device but a regular file, a lot of
programs freeze.
I think a program should deal with weird inputs gracefully especially
when it's not obvious t
Nevermind.
I was pointed at
http://lists.gnu.org/archive/html/bug-bash/2014-03/msg00120.html which
explains the issue.
On 30/01/15 12:13, Øyvind 'bolt' Hvidsten wrote:
Tested with shbot in #bash (freenode):
42# set -u; declare -a foo; echo ${#foo[@]}
0
43# set -u; declare -a foo; echo ${#foo[
Tested with shbot in #bash (freenode):
42# set -u; declare -a foo; echo ${#foo[@]}
0
43# set -u; declare -a foo; echo ${#foo[@]}
bash: foo: unbound variable
43# set -u; foo=(); echo ${#foo[@]}
0
Is this a bug?
12 matches
Mail list logo
