[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dragora-members] Qi 2.0rc14

From: Michael Siegel
Subject: Re: [Dragora-members] Qi 2.0rc14
Date: Sat, 1 Aug 2020 12:39:04 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Am 01.08.20 um 06:27 schrieb Matias Fonzo:
> El 2020-07-31 09:37, Michael Siegel escribió:
>> Am 31.07.20 um 03:29 schrieb Matias Fonzo:
>>> UPDATE: I replaced the current lines with a printf ala:
>>> printf '%s\n' \ " Usage: $PROGRAM COMMAND [OPTIONS] [FILE]... A
>>> simple but well-integrated package manager.
>>> Defaults for the options are specified in brackets.
>>> List of commands: ... "
>>> So much for the need of an external command and the use of 
>>> heredoc...  :-)
>> Well, you've just introduced a subtle way to shoot yourself in the
>> foot because now, every double quote that ever enters that help
>> text better be escaped with a backslash.
>> Using a heredoc – and that would mean using cat(1) – would avoid
>> this problem entirely.
>> So, let me repeat:
>> 1. Speed is not of importance for printing help text. Therefore,
>> using an external command – cat(1), which is part of POSIX – is
>> fine. After all, making use of external commands is largely what
>> Unix shells are built for. 2. Heredocs are safe because they are
>> interpreted as literal strings entirely (using a single-quoted
>> delimiter). 3. printf is not safe for this.
>> So, I would really go with cat(1) and a heredoc. It's less code and
>> it is actually more reliable than the current solution.
> I agree with the speed is not important for printing the help text. 
> While cat(1) is defined by POSIX, printf, too.

Right. What I was meaning to say is that using cat(1) is not like using
rsync(1), for example.

> Note: Using single-quotes makes the value of the variables not
> expand, but this is not a problem right now, as I have removed it.
> It's better this way since the change was made so that the
> configuration file is imported (instead of being parsed), and since
> the script can reflect values that come from the configuration file,
> well...

I don't really get what you're referring to here, sorry. You're probably
talking about that other use of cat(1) in Qi, right?

> My thinking is a little more extreme and paranoid about it since:
> - cat(1) is an external command: If this command is not available
> for some reason, goodbye to printing help.

Okay, but:

  1. If you don't have cat(1) available on a Unix-like, largely
     POSIX-compliant system, something is seriously wrong.

  2. You're checking for the availability of cat(1) before it is used,
     aren't you? So, cat(1) not being available would trigger an error
     and make Qi stop, right?

> - Here documents have tmpfile penalty: Behind the scenes in the shell
> it creates a temporary file every << here document.  Then opens it
> and redirects the input from it.  And removes it after it is done.

I see. But why exactly is this relevant? If it's a performance argument,
I'd say it doesn't really matter.

Have a nice weekend. I'll be working to improve the most horrible part
of the website build script a bit. :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]