Re: [Dragora-members] Qi 2.0rc14

[Matias Fonzo]

El 2020-08-01 19:24, Michael Siegel escribió:
> Am 01.08.20 um 22:08 schrieb Matias Fonzo:
> > El 2020-08-01 07:39, Michael Siegel escribió:
> > > Am 01.08.20 um 06:27 schrieb Matias Fonzo:
>
> [...]
>
> > 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.
>
> [...]
>
> > The only thing that matters that it is not under single quotes is the
> > variable $PROGRAM in the usage (first line, currently).
>
> Ah, okay. Well, I'd simply hard-code "qi" into the help text then. It's
> unlikely to change its name anyway, and it's only two letters.
>
> [...]

It is useful to know where the warning or error messages come from, or 
to reflect usage, in case someone renames the script...

> > > > - 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.
>
> I see. But:
>
>   * Is this even a realistic scenario for Dragora?

Yes and no.  Part of the reliability factor is to consider other 
scenarios, with Dragora's bootstrap method you can create other stages 
for other type of distribution, perhaps embedded.

>   * Shouldn't people who run such a system, i.e., a very non-standard
>     system, know what they're doing and not expect things to just work
>     like on a standard system? I think so.
>
>   * BusyBox has cat(1) too.
>
> So, in short: I'd really just say "No cat(1)? No Qi." You just gotta
> have cat(1). That's really not too much to ask, IMO. It's one of the
> basic tools in the standard Unix toolbox, after all.

If the language offers something native, why make use of something 
external like printing help, plus have the tmpfile penalty.

printf is defined in POSIX, the shell offers it as builtin, and if not, 
it will call the external printf (as fallback :-).

> > >   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/
>
> I see. Well, if cat(1) is being used anywhere, and if only to print 
> help
> text, Qi should check for its availability before using it.

Right, in case we're going to use cat(1).

> Well, I'll just wait for your new RC and then have a look.

We probably won't get anywhere, since this is also about taste and 
style.  I don't have anything against cat(1), just that right now it 
doesn't seem as reliable as using printf.  If it comes to the case that 
for some reason there is a shell that can't print the help, then I will 
gladly switch to cat(1).  ;-)

> > > > - 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).
>
> Okay, but that temporary file will be around 3 kilobytes in size or 
> some
> such, right? Should we really worry about 3kB when it makes sense to 
> use
> them?
>
> I don't know about the second aspect (file system attributes), though.
> I'll try to read up on that if I find the time.

You can try moving /tmp, or setting TMPDIR to another location, also you 
can try playing with `chattr +i' under Extended filesystems.