Re: [Dragora-members] Qi 2.0rc14

[Matias Fonzo]

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,
> > 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?

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