Re: umask --help
On 07/30/2014 07:48 PM, Chet Ramey wrote: > On 7/30/14, 2:44 PM, Notes Jonny wrote: >> On 7 Jul 2014 19:47, "Eric Blake" wrote: >>> >>> On 07/07/2014 12:34 PM, Chris Down wrote: Hi Jon, As is standard with other buitins, umask is documented at `help umask`: >>> >>> That said, POSIX allows, and ksh already supports, the use of --help as >>> an option to ALL builtins. It might be nice if bash were to take a leaf >>> from ksh and add generic support for --help to all builtins, instead of >>> requiring users to remember 'help foo' as yet another item in their >>> arsenal alongside 'info foo', 'man foo', and 'foo --help'. >> >> Sounds good. How best to progress this, as a bugzilla ticket? > > You've already requested it as a new feature. I will evaluate it against > the other requests and implement it if it makes the grade. FWIW +1 for this feature both to minimize diffs between shells, and to have one less likely barrier hit for the important group that is first time users. cheers, Pádraig.
Re: is this fixed in 4.3?
On Wed, Jul 30, 2014 at 02:46:08PM -0700, Linda Walsh wrote: > I just noticed in the 4.2.45 I'm still running that when I > reset my local to standard (LC_ALL=C), it turned off > "vi mode" in my shell ops and turned on emacs mode. I cannot reproduce this. imadev:~$ bash-4.2 imadev:~$ echo $BASH_VERSION 4.2.46(1)-release imadev:~$ set -o | grep -E 'vi|emacs' emacs off privileged off vi on imadev:~$ LC_ALL=C imadev:~$ set -o | grep -E 'vi|emacs' emacs off privileged off vi on How did you "reset your locale"?
Re: read-only flag is lost for functions in sub shells
On 7/30/14, 6:11 PM, Linda Walsh wrote: > If I assigned the read-only bit to an exported var and run a new > shell, that var is still read-only. No: $ ./bash ./x24 4.2.47(4)-release foo = one foo = two $ cat ./x24 echo $BASH_VERSION foo=one readonly foo export foo ./bash -c 'echo foo = $foo ; foo=two ; echo foo = $foo' -- ``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/
Re: Code for :"Re: HERE document failed && Re: /dev/fd/62: No such file or directory"
> but it seemed to work and not be at fault upon further > exploration. Now it's one of 2 Associative arrays (often > called "'map's" in the code where they are used as such) > that is failing due to illegal subscript messages. > > The fact that one of the maps works and the other does not > seems odd. They are both initialized the same way. Have you considered printing the value you're trying to use as a subscript before the failing line is executed? > Is it really the case that now that the problem is better > defined, that it really is just some problem in bash > that can only reproduced on a booting system? Unlikely. -- ``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/
Re: bug? "type -P xxx" returns "xxx" that isn't executable...(or readable)
On 7/30/14, 8:18 PM, Linda Walsh wrote: > Was comparing /contrasting output of "which" with output of "type -[pPa]" > (trying all 3) with the intent of being able to turn which into an alias, > since > it returned incorrect info for "builtins, aliases and functions" -- because > it is a separate program. > > While "which" returns "not found in path when I turn off the exec > bits for "echo", bash still returns the first copy of the file in my > path -- executable or not. No: $ ../bash-4.3-patched/bash ./x25 4.3.22(16)-release PATH = /usr/bin:/bin:/usr/local/bin -rw--- 1 root wheel 14128 Jul 31 09:12 /usr/bin/echo /bin/echo -rwxr-xr-x 1 root wheel 14128 Apr 8 16:15 /bin/echo $ cat ./x25 echo $BASH_VERSION PATH=/usr/bin:/bin:/usr/local/bin echo PATH = $PATH ls -l /usr/bin/echo type -P echo ls -l $(type -P echo) If you already have `echo' in the command hash table, type -P will return it, since that's what the shell will attempt to execute. -- ``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/
Re: read-only flag is lost for functions in sub shells
Chet Ramey wrote: On 7/30/14, 6:11 PM, Linda Walsh wrote: If I assigned the read-only bit to an exported var and run a new shell, that var is still read-only. No: $ ./bash ./x24 4.2.47(4)-release foo = one foo = two $ cat ./x24 echo $BASH_VERSION foo=one readonly foo export foo ./bash -c 'echo foo = $foo ; foo=two ; echo foo = $foo' When did that change? I thought the idea of RO vars being passed to children was considered desirable? (Not that I liked it that much, but am having some of my functions overwritten now when I didn't before... some odd things happening with .bashrc not being read @ login and not sure why, since I thought it was suppose to be read for any interactive shell
Re: is this fixed in 4.3?
Greg Wooledge wrote: On Wed, Jul 30, 2014 at 02:46:08PM -0700, Linda Walsh wrote: I just noticed in the 4.2.45 I'm still running that when I reset my local to standard (LC_ALL=C), it turned off "vi mode" in my shell ops and turned on emacs mode. I cannot reproduce this. Try "unsetting LC_ALL"...
Re: read-only flag is lost for functions in sub shells
On Thu, Jul 31, 2014 at 07:51:01AM -0700, Linda Walsh wrote: > Chet Ramey wrote: > >$ ./bash ./x24 > >4.2.47(4)-release > >foo = one > >foo = two > >$ cat ./x24 > >echo $BASH_VERSION > > > >foo=one > >readonly foo > >export foo > > > >./bash -c 'echo foo = $foo ; foo=two ; echo foo = $foo' > > When did that change? You might be confusing subshells with explicit new process creation. Attributes like readonly are not passed through the environment. How could they be? What out-of-band facility is available to mark environment variables as having these attributes? imadev:~$ cat ./x24 echo "$BASH_VERSION" foo=one readonly foo export foo bash-2.05b -c 'echo "foo=<$foo>"; foo=two; echo "foo=<$foo>"' imadev:~$ bash-2.05b ./x24 2.05b.0(2)-release foo= foo=
Re: is this fixed in 4.3?
On Thu, Jul 31, 2014 at 07:54:33AM -0700, Linda Walsh wrote: > Greg Wooledge wrote: > >On Wed, Jul 30, 2014 at 02:46:08PM -0700, Linda Walsh wrote: > >>I just noticed in the 4.2.45 I'm still running that when I > >>reset my local to standard (LC_ALL=C), it turned off > >>"vi mode" in my shell ops and turned on emacs mode. > > > >I cannot reproduce this. > > Try "unsetting LC_ALL"... imadev:~$ bash-4.2 imadev:~$ set -o | grep -E '^(vi|emacs)' emacs off vi on imadev:~$ unset LC_ALL imadev:~$ set -o | grep -E '^(vi|emacs)' emacs off vi on imadev:~$ LC_ALL=C imadev:~$ set -o | grep -E '^(vi|emacs)' emacs off vi on You'll need to describe what you're doing to trigger the problem.
Re: Code for :"Re: HERE document failed && Re: /dev/fd/62: No such file or directory"
Chet Ramey wrote: but it seemed to work and not be at fault upon further exploration. Now it's one of 2 Associative arrays (often called "'map's" in the code where they are used as such) that is failing due to illegal subscript messages. The fact that one of the maps works and the other does not seems odd. They are both initialized the same way. Have you considered printing the value you're trying to use as a subscript before the failing line is executed? It's been a while, but I seem to remember doing that and setting -x at the beginning of the script and picking through that post-boot. I try it again... might easily get a different result with how things are going for me lately...
Extra '-i' file in Bash repo
Hello there, Commit 43aebe922bc2a614c410e282fdf772e063454168 added an empty file named '-i' at the root of the Bash repo. This might be an elaborate trick to auto-add the -i flag to all commands run with * as argument in the repo directory, or a mistake. Just thought I'd mention it in case it's the latter. Regards, Quentin
Re: Extra '-i' file in Bash repo
On 7/31/14, 7:08 AM, Quentin Minster wrote: > > Hello there, > > Commit 43aebe922bc2a614c410e282fdf772e063454168 added an empty file > named '-i' at the root of the Bash repo. This might be an elaborate > trick to auto-add the -i flag to all commands run with * as argument in > the repo directory, or a mistake. > Just thought I'd mention it in case it's the latter. The former. I've used that trick for a long time. -- ``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/
Re: read-only flag is lost for functions in sub shells
On 7/31/14, 10:51 AM, Linda Walsh wrote: > > > Chet Ramey wrote: >> On 7/30/14, 6:11 PM, Linda Walsh wrote: >>> If I assigned the read-only bit to an exported var and run a new >>> shell, that var is still read-only. >> >> No: >> >> $ ./bash ./x24 >> 4.2.47(4)-release >> foo = one >> foo = two >> $ cat ./x24 >> echo $BASH_VERSION >> >> foo=one >> readonly foo >> export foo >> >> ./bash -c 'echo foo = $foo ; foo=two ; echo foo = $foo' > > When did that change? It's always been that way. Maybe you could post some (minimal) sample code you're using that illustrates the problem you're having. > I thought the idea of RO vars being passed to children was considered > desirable? As Greg says, there's no existing mechanism to do that using the environment, which is the only way to communicate across exec(2). I could invent something, but what would be the point? > (Not that I liked it that much, but am having some of my functions > overwritten now when I didn't before... some odd things happening with .bashrc > not being read @ login and not sure why, since I thought it was suppose to > be read for any interactive shell No: "When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists." -- ``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/
Re: read-only flag is lost for functions in sub shells
On Thu, 31 Jul 2014, Chet Ramey wrote:
On 7/31/14, 10:51 AM, Linda Walsh wrote:
...
I thought the idea of RO vars being passed to children was considered
desirable?
As Greg says, there's no existing mechanism to do that using the
environment, which is the only way to communicate across exec(2). I
could invent something, but what would be the point?
It's not hard to do, e.g. as a comma-separated list of readonly
variables:
export READONLY_VARS=foo,bar,why,not foo bar why not
In the receiving script:
if [[ -n $READONLY_VARS ]]
then
IFS=, read -a rov <<< "$READONLY_VARS"
readonly "${rov[@]}"
fi
foo=q ## not permitted
--
Chris F.A. Johnson,
Re: read-only flag is lost for functions in sub shells
On 7/31/14, 3:36 PM, Chris F.A. Johnson wrote: > On Thu, 31 Jul 2014, Chet Ramey wrote: >> On 7/31/14, 10:51 AM, Linda Walsh wrote: > ... >>> I thought the idea of RO vars being passed to children was considered >>> desirable? >> >> As Greg says, there's no existing mechanism to do that using the >> environment, which is the only way to communicate across exec(2). I >> could invent something, but what would be the point? > > It's not hard to do, e.g. as a comma-separated list of readonly > variables: > > export READONLY_VARS=foo,bar,why,not foo bar why not Sure. You're inventing an out-of-band communication mechanism that uses the environment. The advantage of this is that it's done outside the shell at the script level. 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/
Re: bug? "type -P xxx" returns "xxx" that isn't executable...(or readable)
Chet Ramey wrote: On 7/31/14, 10:55 AM, Linda Walsh wrote: Chet Ramey wrote: On 7/30/14, 8:18 PM, Linda Walsh wrote: Was comparing /contrasting output of "which" with output of "type -[pPa]" (trying all 3) with the intent of being able to turn which into an alias, since it returned incorrect info for "builtins, aliases and functions" -- because it is a separate program. While "which" returns "not found in path when I turn off the exec bits for "echo", bash still returns the first copy of the file in my path -- executable or not. No: Ahhh... so that one's fixed in 4.3... yeay! No: $ ../bash-4.3-patched/bash ./x25 4.3.22(16)-release PATH = /usr/bin:/bin:/usr/local/bin -rw--- 1 root wheel 14128 Jul 31 09:12 /usr/bin/echo /bin/echo -rwxr-xr-x 1 root wheel 14128 Apr 8 16:15 /bin/echo -=--- This is what I am doing: Ishtar:/> hash -r#shouldn't affect -P but doing it anyway Ishtar:/> type -P echo /usr/bin/echo Ishtar:/> /usr/bin/echo -bash: /usr/bin/echo: Permission denied Ishtar:/> ll /usr/bin/echo --w--- 2 136753 Nov 19 2013 /usr/bin/echo === I.e. type -P returns /usr/bin/echo as an executable in my path when it is not an executable.
Re: read-only flag is lost for functions in sub shells
Greg Wooledge wrote: On Thu, Jul 31, 2014 at 07:51:01AM -0700, Linda Walsh wrote: Chet Ramey wrote: $ ./bash ./x24 4.2.47(4)-release foo = one foo = two $ cat ./x24 echo $BASH_VERSION foo=one readonly foo export foo ./bash -c 'echo foo = $foo ; foo=two ; echo foo = $foo' When did that change? You might be confusing subshells with explicit new process creation. I think you are right. I'm having odd symptoms right now not sure what changed, but my .bashrc file and .bash_env files are not longer read on login. Stuff done by them used to be done...but now is not. (i.e. either something else provided the same function calls or something called them). Also noticing broken-ness upon using "sudo" -- functions defined at login are undefined: typeset -f|grep titlebar titlebar () declare -fx titlebar side note (I think the above is why I thought it was sent to children -- thought the declare was in my environment) i.e. if I type: typeset -p, I see vars that are "read-only" with a "declare -rx", like: declare -rx foo="37" I think I thought that was passed through the environment, as I have stored such declares in a var for later execution: i.e. echo $_GPSAFE_ declare -Ax _GROUPS_='([atusers]="238" [tty]="5" [mediatomb]="244" [Juno]="231" [scan]="232" . [trusted]="42" [lawgroup]="201" ["Group Policy Creator Owners"]="520" [docker]="499" [powerd]="204" [lock]="54" [audio]="17" )' I store the declare statement for my $_GROUPS_ array as a string, so I can recreate it by eval'ing the string, and though bash did that for r/o vars... my bad... ---/endside note/--- Also noticing broken-ness upon using "sudo" -- functions defined at login are undefined: typeset -f|grep titlebar titlebar () declare -fx titlebar /> sudo bash: titlebar: command not found Ishtar:/> ^^^ prompt doesn't change to "#" nor to "red" ... as used to. Either sudo has always stripped out functions (it isn't stripping my environment other than functions), and something else something else redefined them, OR sudo changed. Hmmm.I think I installed a package for bash completions yesturday... maybe that mucked things up... Sorry for the various line noise... but this is sorta confusing...
Re: bug? "type -P xxx" returns "xxx" that isn't executable...(or readable)
Chet Ramey wrote:
type -P echo
ls -l $(type -P echo)
If you already have `echo' in the command hash table, type -P will return
it, since that's what the shell will attempt to execute.
---
It's not in the hash table, but type -P still
returns the non-executable.
Ishtar:/> ll {,/usr}/bin/echo
-rw-r--r-- 2 136753 Nov 19 2013 /bin/echo
--w--- 2 136753 Nov 19 2013 /usr/bin/echo
sudo chmod +x /bin/echo
Ishtar:/> type -P echo
/bin/echo #correct
Ishtar:/> sudo chmod -x /bin/echo#take it away
Ishtar:/> hash -r#in theory, purge command hash
Ishtar:/> type -P echo #but doesn't use last lookup
/usr/bin/echo #switches to returning /usr/bin
copy
Assuming my hash -r was ignored, and -P would
still deliver the last command used, it should have returned
/bin/echo... but "/bin/echo" is no longer readable
Shouldn't it return "null" or empty string?
i.e. I thought I could check for an executable by doing
a lookup with -P (not for builtins, obviously) for non
builtins, seems that's not safe? Shouldn't it be?
