[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: Mon, 03 Aug 2020 09:51:52 -0300
User-agent: Roundcube Webmail/1.4.6

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

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.

reply via email to

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