dragora-members
[Top][All Lists]
Advanced

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

Re: [Dragora-members] Qi 2.0rc10


From: Michael Siegel
Subject: Re: [Dragora-members] Qi 2.0rc10
Date: Tue, 14 Jul 2020 14:52:22 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Am 14.07.20 um 13:20 schrieb Matias Fonzo:
> Hi Michael,
> 
> Thanks for taking the time in review Qi 2.0rc10! ;-)
> 
> El 2020-07-13 14:38, Michael Siegel escribió:
>> Am 04.07.20 um 22:35 schrieb Matias Fonzo:
>>>
>>> Qi 2.0rc10 for review, attached.
>>
>> Okay, I'll keep this concise. This is just what I found having a rather
>> quick look over the source.
>>
>>   * L 46: Usage: $PROGRAM COMMAND [OPTION...] [FILE]...
>>     * POSIX would also allow for simply saying "[OPTIONS]"[1]. I think
>>       that's a good way to do it in this case.
>>     * POSIX is not really clear on this, but I think it should rather be
>>       "[FILE...]".
>>     * This should then also be adjusted in the manual page.
> 
> I changed it to [OPTIONS].  While [FILE]... prevails as I see nothing
> wrong with it, it is widely used in GNU tools.

Okay, I see. My impression is that the POSIX description of how to do
that exactly right is so confusing that, basically, everyone has their
own way of doing it. And if GNU says [FILE]..., then let it be that.

>>   * L 112, 380: printf "%s\\n"
>>     * Wouldn't it be better to say: printf '%s\n'
> 
> Yes.  This was pointed by
> https://github.com/koalaman/shellcheck/wiki/SC1117 before.
> I changed it to printf '%s\n' now.

Nice.

[...]

>>   * L 1506: \unalias -a;        # Unset all possible aliases.
>>     * Why is there a backslash before "unalias"?
> 
> To avoid invoking a possible alias of "unalias".

Yeah, I just found it in POSIX and wanted to tell you to ignore this
question, but you were quicker. :)

>>     * Also, I'm not sure if that is needed because, usually aliases
>>       don't apply when running scripts, IIRC. We'd need to verify that
>>       in POSIX, mksh(1) and the Bash Reference Manual.
> 
> This would put off any possible declaration of aliases from the
> configuration file, I'm not sure if anyone will declare useful aliases
> there to be used in the recipe...

I see.

>> Generally, I'd go through the code again and look for unquoted variable
>> expansions and decide whether to better quote them or not. I mean, it is
>> more consistent to just quote every substitution, except for where you
>> don't quote things on purpose, I think.
> 
> Agree.  I will take a look on the code for such cases.
> 
>> Also, maybe you could convert all usage of `echo' to `printf'. Maybe
>> that would even be more convenient/practical in some cases.
> 
> I use echo (without options) to print a few lines or lines that I feel
> will have no special formatting.  Printf is quite useful when you want
> formatting and fast when printing several lines in one go.

Yeah, that's probably fine. You don't actually need the "" in those
cases, though. It could just be `echo' (says POSIX). But that's not
really important.

>> Last but not least, I'd say the argument parsing should be done a bit
>> differently, but I'd have to have a closer look on exactly how it should
>> be done. The basic idea is: Parse global options first, then parse
>> commands and have the function implementing a particular command parse
>> its respective options.
>>
> 
> Yes and no.
> 
> That's what I did before when I was trying to implement the new
> interface.  I found this to be both impractical and confusing, as it
> adds a third (optional) level to the command line order or attempt.
> 
> Consider that for the global option to work, the program needs a command
> as an argument, which is mandatory.  The global option would then
> fulfill its function based on a specific command.  So, in Qi, there are
> no global options as such (that is, general options that apply to all
> commands); instead, these are common options that can exist between one
> command and another, currently there are no options in Qi that apply to
> all commands.
> 
> Global options seem to be an illusion more than anything else, in
> practice you could type:
> 
>     qi -N install package.tlz
> 
> Note that -N in the first position (before the command) is a Global
> option.  But if you or someone forgets to type the -G option at this
> position, you'll want to match the option for the "install" command
> after it, so that it takes effect:
> 
>     qi install -N package.tlz
> 
> Not to mention that making the global options require a little more code
> in Qi to work, and this will be optional, since the user may not write
> the global option in that corresponding position.
> 
> It's clearer and simpler if you know what the order of Qi's interface is:
> 
>     qi COMMAND [OPTIONS] [FILE]...

Okay, I'll have to think about this again. In the meantime, you could
have a look at

  https://vcs.malbolge.net/msi/mote/-/blob/master/mote#L1056

for a code example of what I meant. Maybe that doesn't make sense for
Qi, though. Anyway, let's just leave it as it is for 2.0, if it works
reliably.

There were a few more issues when I ran shellcheck on rc10, the most
important being:

  In qi.in line 543:
              echo ",s/^\\(release\\)=.*/\\1=${release}/"$'\nw' | \
                                                         ^-- SC2039: In
  POSIX sh, $'..' is undefined.


  In qi.in line 881:
                      rm -rf -- "$rootdir${packagedir}/$replace"
                                ^-- SC2115: Use "${var:?}" to ensure
  this never expands to / .


  In qi.in line 1060:
      PRVDIR="${TMPDIR}/${name}.${RANDOM-0}$$"
                                ^-- SC2039: In POSIX sh, RANDOM is
  undefined.



Best
Michael



reply via email to

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