[Top][All Lists]

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

Re: [Dragora-members] Qi 2.0rc14

From: Matias Fonzo
Subject: Re: [Dragora-members] Qi 2.0rc14
Date: Sat, 01 Aug 2020 17:08:19 -0300
User-agent: Roundcube Webmail/1.4.6

El 2020-08-01 07:39, Michael Siegel escribió:
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.

I see.

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,

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?

I'm talking about that the block text on the usage() contains variables names to be reflected, such as $jobs.

If you use single quotes, like cat << 'EOF' it won't be expanded, the value will not be reflected.

Actually, I've removed it, it's better that way because it may also show the value from the configuration file, and if someone assigns something that is not, then it breaks this, e.g.: jobs=$(ls) (from the configuration file).

The only thing that matters that it is not under single quotes is the variable $PROGRAM in the usage (first line, currently).

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.

Yes, of course. It would be strange, though not impossible. If the scenario is an embedded system, cat(1) may not be available there, nor would a shell make much sense, but you never know.

  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?

This is not after usage() or when you pass --help; it is before checking the targetdir and rootdir directories, before entering the loop for the action, currently.

There is no need to check cat(1), I already changed it, I modified the do_meta() function to make it more efficient. As soon as I can I will send another RC, I am still implementing the SOURCE_DATE_EPOCH environment variable[1] (tarlz 0.17 has been released and now supports the --mtime option that I requested ;-).

[1] https://reproducible-builds.org/specs/source-date-epoch/

- 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.

It relates to space and file system attributes. It is based on TMPDIR (or /tmp if not defined).

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

Thank you, you too! - I'll try to be on the website content as soon as I find the time. :-)

reply via email to

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