Re: umask --help
On 10 Oct 2014 01:25, "Chet Ramey" wrote: > > On 10/9/14, 3:05 PM, Notes Jonny wrote: > > >> If and when it happens, it will > >> show up in the devel git branch on savannah. > >> > >> Chet > > > Thank you for your reply. > > > > I understand that requests can't be implemented immediately. > > > > Is there anything I could do to get this implemented? Eg. I would offer to > > pay £100 for an engineer to complete the updates. > > Did you check the devel git branch on savannah? :-) > > The changes went in in early September. Fantastic. Thanks :-) Jonny
Re: umask --help
On 2 Sep 2014 16:48, "Chet Ramey" wrote: > > On 9/2/14, 5:37 AM, Notes Jonny wrote: > > > Hi Guys > > > > Any update on implementing this? > > I haven't done anything with this yet. If and when it happens, it will > show up in the devel git branch on savannah. > > Chet > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/ Thank you for your reply. I understand that requests can't be implemented immediately. Is there anything I could do to get this implemented? Eg. I would offer to pay £100 for an engineer to complete the updates. Regards Jonny
Re: hashlib.c add NULL check for "string" parameter
On Mon, Sep 29, 2014 at 2:04 PM, Chet Ramey wrote: > On 9/29/14, 8:22 AM, Notes Jonny wrote: >> Hello >> I noticed hash_search() did not check if "string" parameter was >> non-NULL. Please find attached a patch for this. > > It's the caller's responsibility to ensure that the string passed to > hash_search is non-NULL. What's your rationale for that? CERT EXP34-C "Do not dereference null pointers" is pretty clear, with examples: https://www.securecoding.cert.org/confluence/display/seccode/EXP34-C.+Do+not+dereference+null+pointers In software development we always verify parameters are within expected bounds. There is ISO/IEC TR 24772 covering this topic amongst others. Regards, Jonny
hashlib.c add NULL check for "string" parameter
Hello I noticed hash_search() did not check if "string" parameter was non-NULL. Please find attached a patch for this. There are others similar. So I will wait and see if you are happy with these kind of changes, and if so I can submit more when I have analysed. I'm not on this list, so please include my email address in any replies. Regards, Jonny hashlib_c.patch Description: Binary data
Re: umask --help
On Thu, Jul 31, 2014 at 11:18 AM, Pádraig Brady wrote: > 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. Hi Guys Any update on implementing this? Regards, Jonny
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 Mon, Jul 7, 2014 at 7:34 PM, Chris Down wrote: > Hi Jon, > > As is standard with other buitins, umask is documented at `help umask`: > > chris@gopher:~$ help umask > umask: umask [-p] [-S] [mode] > Display or set file mode mask. > > Sets the user file-creation mask to MODE. If MODE is omitted, prints > the current value of the mask. > > If MODE begins with a digit, it is interpreted as an octal number; > otherwise it is a symbolic mode string like that accepted by chmod(1). > > Options: > -pif MODE is omitted, output in a form that may be reused as > input > -Smakes the output symbolic; otherwise an octal number is output > > Exit Status: > Returns success unless MODE is invalid or an invalid option is given. > > The umask builtin is also documented in `man bash`. Thank you for the tips. I see it now. Could this information be added to the places that don't currently refer to it? e.g. these two places: A) --help: -- Please see "help umask" for documentation B) man umask: Please see "help umask" for documentation Saving the need to hunt it down.. Thanks, Jon
umask --help
Hello Thank you for developing bash. I am using GNU Bash-4.0 Would you consider adding a --help option for "umask" please? (I understand this is a built in command) Maybe also --version I was just hoping to find some help for it. "info umask" and "man umask" also don't say anything. Regards, Jon
