[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Dragora-members] Qi 2.0rc14
Re: [Dragora-members] Qi 2.0rc14
Sat, 01 Aug 2020 17:08:19 -0300
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
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,
I don't really get what you're referring to here, sorry. You're
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
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.
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
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 (tarlz 0.17 has been released and now supports
the --mtime option that I requested ;-).
- 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
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. :-)