All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: phillip.wood@dunelm.org.uk
Cc: Git Mailing List <git@vger.kernel.org>,
	carenas@gmail.com,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH 4/4] terminal: restore settings on SIGTSTP
Date: Mon, 07 Mar 2022 12:49:37 +0100	[thread overview]
Message-ID: <220307.86ilsq0xxr.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <8aa11144-c9ce-46aa-2edd-15e8fa1298dc@gmail.com>


On Mon, Mar 07 2022, Phillip Wood wrote:

> Hi Ævar
>
> On 05/03/2022 13:59, Ævar Arnfjörð Bjarmason wrote:
>> [...] 
>>>   int save_term(unsigned flags)
>>>   {
>>> +	struct sigaction sa;
>>> +
>>>   	if (term_fd < 0)
>>>   		term_fd = (flags & SAVE_TERM_STDIN) ? 0
>>>   						    : open("/dev/tty", O_RDWR);
>>> @@ -44,6 +136,26 @@ int save_term(unsigned flags)
>>>   	if (tcgetattr(term_fd, &old_term) < 0)
>>>   		return -1;
>>>   	sigchain_push_common(restore_term_on_signal);
>>> +	/*
>>> +	 * If job control is disabled then the shell will have set the
>>> +	 * disposition of SIGTSTP to SIG_IGN.
>>> +	 */
>>> +	sigaction(SIGTSTP, NULL, &sa);
>>> +	if (sa.sa_handler == SIG_IGN)
>>> +		return 0;
>>> +
>>> +	/* avoid calling gettext() from signal handler */
>>> +	background_resume_msg = xstrdup(_("error: cannot resume in the background"));
>>> +	restore_error_msg = xstrdup(_("error: cannot restore terminal settings"));
>> You don't need to xstrdup() the return values of gettext() (here
>> _()),
>> you'll get a pointer to static storage that's safe to hold on to for the
>> duration of the program.
>
> I had a look at the documentation and could not see anything about the
> lifetime of the returned string, all it says is "don't alter it"

I think this is overed in "11.2.7 Optimization of the *gettext
functions", a pedantic reading might suggest not, but what's meant with
the combination of that API documentation & the description of how MO
files work is that you're just getting pointers into the already-loaded
translation catalog, so it's safe to hold onto the pointer and re-use it
later.

In any case, if we're going to be paranoid about gettext() it would make
sense to propose that as some general change to how we use it, we rely
on this assumption holding in a lot of our use of the API:

    git grep '= _\('

Rather than sneak that partcular new assumption in here in this already
tricky code...

>> In this case I think it would make sense to skip "error: " from the
>> message itself.
>> Eventually we'll get to making usage.c have that prefix translated,
>> and
>> can have some utility function exposed there (I have WIP patches for
>> this already since a while ago).
>> To translators it'll look like the same thing, and avoid churn when
>> we
>> make the "error: " prefix translatable.
>
> Unless we add a function that returns a string rather than printing
> the message I don't see how it avoids churn in the future. Having the
> whole string with the "error: " prefix translated here does not add
> any extra burden to translators - it is still the same number of
> strings to translate.

Because translators translate "we failed" for most errors, not "error:
we failed".

If and when we convert it from "error: we failed" to "we failed" they'll
need to translate it again (although to be fair, the translation cache
will help).

And even then it'll be one of very few exceptions where the "error: "
currently that *is* translated.

>> Aside: If you do keep the xstrdup() (perhaps an xstrfmt() with the above
>> advice...) doesn't it make sense to add the "\n" here, so you'll have
>> one write_in_full() above?
>
> I decided to keep the translated string simpler by omitting the
> newline, calling write_in_full() twice isn't a bit deal (I don't think
> the output can be split by a write from another thread or signal
> handler in between).

Makes sense.

FWIW I meant if you're going to xstrdup() or xstrfmt() it anyway you
could do:

    xstrfmt("error: %s\n", _("the error"))

And then do one call to write_in_full().

But I think just:

    msg = _("the error");

And then:

	const char *const = pfx = "error: ";
        const size_t len = strlen(pfx);

	write_in_full(2, pfx, len);
        write_in_full(2, msg, strlen(msg));
	write_in_full(2, "\n", 1);

Makes more sense :)

  reply	other threads:[~2022-03-07 12:06 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-04 13:11 [PATCH 0/4] builtin add -p: hopefully final readkey fixes Phillip Wood
2022-03-04 13:11 ` [PATCH 1/4] terminal: use flags for save_term() Phillip Wood
2022-03-04 20:40   ` Ramsay Jones
2022-03-07 11:11     ` Phillip Wood
2022-03-07 20:21       ` Ramsay Jones
2022-03-08 10:41         ` Phillip Wood
2022-03-05 14:02   ` Ævar Arnfjörð Bjarmason
2022-03-07 10:45     ` Phillip Wood
2022-03-07 12:06       ` Ævar Arnfjörð Bjarmason
2022-03-04 13:11 ` [PATCH 2/4] terminal: don't assume stdin is /dev/tty Phillip Wood
2022-03-04 20:42   ` Ramsay Jones
2022-03-04 13:11 ` [PATCH 3/4] terminal: work around macos poll() bug Phillip Wood
2022-03-04 13:11 ` [PATCH 4/4] terminal: restore settings on SIGTSTP Phillip Wood
2022-03-05 13:59   ` Ævar Arnfjörð Bjarmason
2022-03-07 10:53     ` Phillip Wood
2022-03-07 11:49       ` Ævar Arnfjörð Bjarmason [this message]
2022-03-07 13:49         ` Phillip Wood
2022-03-07 14:45           ` Ævar Arnfjörð Bjarmason
2022-03-08 10:54             ` Phillip Wood
2022-03-09 12:19   ` Johannes Schindelin
2022-03-10 16:06     ` Phillip Wood
2022-03-09 11:03 ` [PATCH v2 0/4] builtin add -p: hopefully final readkey fixes Phillip Wood
2022-03-09 11:03   ` [PATCH v2 1/4] terminal: use flags for save_term() Phillip Wood
2022-03-11 16:52     ` Carlo Arenas
2022-03-14 10:49       ` Phillip Wood
2022-03-09 11:03   ` [PATCH v2 2/4] terminal: don't assume stdin is /dev/tty Phillip Wood
2022-03-09 11:03   ` [PATCH v2 3/4] terminal: work around macos poll() bug Phillip Wood
2022-03-10 13:35     ` Ævar Arnfjörð Bjarmason
2022-03-10 16:02       ` Phillip Wood
2022-03-10 18:02         ` Junio C Hamano
2022-03-09 11:03   ` [PATCH v2 4/4] terminal: restore settings on SIGTSTP Phillip Wood
2022-03-09 23:10   ` [PATCH v2 0/4] builtin add -p: hopefully final readkey fixes Junio C Hamano
2022-03-09 23:37     ` Junio C Hamano
2022-03-10 13:28       ` Phillip Wood
2022-03-10 18:18         ` Phillip Wood
2022-03-10 18:53           ` Junio C Hamano
2022-03-10 13:25   ` Johannes Schindelin
2022-03-10 16:08     ` Phillip Wood
2022-03-15 10:57 ` [PATCH v3 " Phillip Wood
2022-03-15 10:57   ` [PATCH v3 1/4] terminal: use flags for save_term() Phillip Wood
2022-03-15 10:57   ` [PATCH v3 2/4] terminal: don't assume stdin is /dev/tty Phillip Wood
2022-03-15 17:42     ` Junio C Hamano
2022-03-15 18:01       ` rsbecker
2022-03-15 19:05         ` Junio C Hamano
2022-03-15 19:38           ` rsbecker
2022-03-15 10:57   ` [PATCH v3 3/4] terminal: work around macos poll() bug Phillip Wood
2022-03-15 10:57   ` [PATCH v3 4/4] terminal: restore settings on SIGTSTP Phillip Wood
2022-03-15 17:51     ` Junio C Hamano
2022-03-16 18:54 ` [PATCH v4 0/4] builtin add -p: hopefully final readkey fixes Phillip Wood
2022-03-16 18:54   ` [PATCH v4 1/4] terminal: use flags for save_term() Phillip Wood
2022-03-16 18:54   ` [PATCH v4 2/4] terminal: don't assume stdin is /dev/tty Phillip Wood
2022-03-16 18:54   ` [PATCH v4 3/4] terminal: work around macos poll() bug Phillip Wood
2022-03-16 18:54   ` [PATCH v4 4/4] terminal: restore settings on SIGTSTP Phillip Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=220307.86ilsq0xxr.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=carenas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood@dunelm.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.