Re: Untranslatable string in help.def
On 9/15/19 12:50 PM, Roland Illig wrote:
> Hi,
>
> in help.def, the code reads:
>
> if (glob_pattern_p (list->word->word))
> {
> printf ("%s", ngettext ("Shell commands matching keyword `",
> "Shell commands matching keywords `", (list->next ? 2 : 1)));
> print_word_list (list, ", ");
> printf ("'\n\n");
> }
>
> The strings for translations should always be a complete sentence since
> in some languages the word order can differ.
It's difficult to provide a translation for a string whose contents are
determined at runtime based on user input. That's why we're using
ngettext here, so we can try to get the appropriate plural form. I can
certainly change the single quote to be translatable, so that might
provide the desired flexibility.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: help for "(( ))" uses straight quotes
On 9/15/19 4:07 PM, Roland Illig wrote: > The help for "(( ))" says: > >> evaluation. Equivalent to "let EXPRESSION". > > All other help topics use `these' quotes. Thanks, it should be let "EXPRESSION", with or without the `' quotes, as it is in the man page. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: typo in internal warning: the_pipeline
On 9/15/19 2:01 PM, Roland Illig wrote:
> internal_warning (_("add_process: process %5ld (%s) in the_pipeline"),
> (long)p->pid, p->command);
>
> What does "the_pipeline" mean?
PROCESS *the_pipeline = (PROCESS *)NULL;
>
> And why is an internal warning translated anyway?
It indicates an anomalous but non-fatal condition that indicates a possible
bug, so it's a message like any other. You'd like the user to know what it
is and, I hope, report it.
In this case, that doesn't really matter because the message is #ifdef
DEBUG and won't appear in production releases, so it probably doesn't need
to be translated.
The real bug is that there are some untranslated calls in jobs.c that
aren't protected by #ifdef DEBUG.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: trailing whitespace in shortdoc
On 9/15/19 3:29 PM, Roland Illig wrote: > The command "help alias | sed s,$,$," prints some lines with trailing > whitespace. What is the purpose of this trailing whitespace? If there is > none, it should not be generated at all. I can't reproduce this. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: possible buffer overflow by bad translation
On 9/15/19 2:24 PM, Roland Illig wrote:
> From siglist.c:
>
> sys_siglist[i] =
> (char *)xmalloc (10 + strlen (_("Unknown Signal #")));
>
> sprintf (sys_siglist[i], _("Unknown Signal #%d"), i);
I'll figure something out. This code is used in exceedingly rare
circumstances: where a system doesn't provide sys_siglist[] or
strsignal(). You probably haven't used one in years.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Wrong explanation of getopts
On 9/15/19 3:57 PM, Roland Illig wrote: > The help text of getopts says: > >> Getopts normally parses the positional parameters ($0 - $9), but if >> more arguments are given, they are parsed instead. > > The positional parameter $0 (is it even called that way) is not parsed > by getopts. Its only use might be in error messages, but I'm not sure > about it. You're right; getopts doesn't use $0 at this time. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
[repost] "precision" of $SECONDS
That's a a re-post of a bug report I raised a few years ago and comes back now and then in various Q&A sites I participate in. The discussions kind of trailed off last time. https://www.mail-archive.com/bug-bash@gnu.org/msg17783.html 2016-02-24 15:16:41 +, Stephane Chazelas: > $ time bash -c 'while ((SECONDS < 1)); do :; done' > bash -c 'while ((SECONDS < 1)); do :; done' 0.39s user 0.00s system 99% cpu > 0.387 total > > That can take in between 0 and 1 seconds. Or in other words, > $SECONDS becomes 1 in between 0 and 1 second after the shell was > started. > > The reason seems to be because the shell records the value > returned by time() upon start-up and $SECONDS expands to > time()-that_saved_time. So, if bash is started at 10:00:00.999, > then $SECONDS will become 1 only a milisecond after startup > while if it's started at 10:00:01.000, $SECONDS will become 1 a > full second later. > > IMO, it would be better if gettimeofday() or equivalent was used > instead of time() so that $SECONDS be incremented exactly one > second after start-up like ksh93 does. > > mksh and zsh behave like bash (I'll raise the issue there as > well). > > With zsh (like in ksh93), one can do "typeset -F SECONDS" to > make $SECONDS floating point, which can be used as a work around > of the "issue". [...] Note that since then the corresponding bugs in mksh and zsh have been fixed. -- Stephane
