Re: umask --help
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? Regards Jonny
Re: umask --help
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. 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/
is this fixed in 4.3?
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. Has this been fixed? Thanks..
read-only flag is lost for functions in sub shells
If I assigned the read-only bit to an exported var and run a new shell, that var is still read-only. However, doing the same with an exported function seems to drop the read-only status. If read-only status is supposed to be immutable, wouldn't is this desirable? (bash 4.2)
Re: Code for :"Re: HERE document failed && Re: /dev/fd/62: No such file or directory"
I got various suggestions for getting my script to work at boot time, and any of them might have been applicable before I'd gotten to the current problem... In particular the <<<"$VAR" construct where VAR was holding output from a program.. was something on my "iffy" list, 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. I've also tried resetting the environment... (env -i bash --norc --noprofile; bash-4.2$ ...command works...) 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? Note -- if you invoke the script with with no parms, it display normal options "ifmap" (shows current mapping) and "remap" which does a verify on the names and does renaming if needed (based on it's internal table -- i.e. don't use this unless you've adapted it to your system). undocumented: if you invoke it with 'start' it does the "remap" function. Other than a few left-over functions from earlier debug attempts (tests removed, but some of the functions remain so I can maybe move them to a library later (e.g. - isarray & varflags), it is fairly lean for design of non-throwaway code.
bug? "type -P xxx" returns "xxx" that isn't executable...(or readable)
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. Shouldn't it only be returning the first *executable* version of what is found (if anything?) ... i.e. type -P echo /usr/bin/echo \ls -l /usr/bin/echo cat /usr/bin/echo cat: /usr/bin/echo: Permission denied \ls -l /usr/bin/echo -rw--- 2 root root 136753 Nov 19 2013 /usr/bin/echo
