Suggest to use more long options arguments at /etc/makepkg.conf
I think long command line options are more readable compared to short one. There fore, I suggest: --- a/makepkg.conf 2022-12-12 17:00:57.773722168 +0000 +++ b/makepkg.conf 2022-12-12 18:00:46.612320662 +0000 @@ -9,11 +9,11 @@ # #-- The download utilities that makepkg should use to acquire sources # Format: 'protocol::agent' -DLAGENTS=('file::/usr/bin/curl -qgC - -o %o %u' - 'ftp::/usr/bin/curl -qgfC - --ftp-pasv --retry 3 --retry-delay 3 -o %o %u' - 'http::/usr/bin/curl -qgb "" -fLC - --retry 3 --retry-delay 3 -o %o %u' - 'https::/usr/bin/curl -qgb "" -fLC - --retry 3 --retry-delay 3 -o %o %u' - 'rsync::/usr/bin/rsync --no-motd -z %u %o' +DLAGENTS=('file::/usr/bin/curl --disable --globoff --continue-at - --output %o %u' + 'ftp::/usr/bin/curl --disable --globoff --fail --continue-at - --ftp-pasv --retry 3 --retry-delay 3 --output %o %u' + 'http::/usr/bin/curl --disable --globoff --cookie "" --fail --location --continue-at - --retry 3 --retry-delay 3 --output %o %u' + 'https::/usr/bin/curl --disable --globoff --cookie "" --fail --location --continue-at - --retry 3 --retry-delay 3 --output %o %u' + 'rsync::/usr/bin/rsync --no-motd --compress %u %o' 'scp::/usr/bin/scp -C %u %o') # Other common tools: @@ -134,15 +134,15 @@ # COMPRESSION DEFAULTS ######################################################################### # -COMPRESSGZ=(gzip -c -f -n) -COMPRESSBZ2=(bzip2 -c -f) -COMPRESSXZ=(xz -c -z -) -COMPRESSZST=(zstd -c -z -q -) -COMPRESSLRZ=(lrzip -q) -COMPRESSLZO=(lzop -q) +COMPRESSGZ=(gzip --to-stdout --force --no-name) +COMPRESSBZ2=(bzip2 --stdout --force) +COMPRESSXZ=(xz --to-stdout --compress -) +COMPRESSZST=(zstd --stdout --compress --quiet -) +COMPRESSLRZ=(lrzip --quiet) +COMPRESSLZO=(lzop --quiet) COMPRESSZ=(compress -c -f) -COMPRESSLZ4=(lz4 -q) -COMPRESSLZ=(lzip -c -f) +COMPRESSLZ4=(lz4 --quiet) +COMPRESSLZ=(lzip --stdout --force) ######################################################################### # EXTENSION DEFAULTS -- u34
Hi u34,
I think long command line options are more readable compared to short one. There fore, I suggest:
I think the short one-letter names combined into a single ‘-’ are more readable, as I suspect do many others accustomed to their decades-long use across all Unix commands, so I suggest things stay as they are. :-) -- Cheers, Ralph.
Hi! I think the short one-letter names combined into a single ‘-’ are more
readable, as I suspect do many others accustomed to their decades-long use across all Unix commands, so I suggest things stay as they are. :-)
Well I think like u34, even for an experienced user the short options of the commands can generate doubts. While it is true that these are cleared by simply looking at the manual page, this step can almost always be skipped when dealing with long options that are more self-explanatory. Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
On Tue, 13 Dec 2022 at 07:25, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
Hi u34,
I think long command line options are more readable compared to short one. There fore, I suggest:
I think the short one-letter names combined into a single ‘-’ are more readable, as I suspect do many others accustomed to their decades-long use across all Unix commands, so I suggest things stay as they are. :-)
The added benefit is that the short options are faster to search for in the man page.
Lukas Jirkovsky <l.jirkovsky@gmail.com> wrote:
On Tue, 13 Dec 2022 at 07:25, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
Hi u34,
I think long command line options are more readable compared to short one. There fore, I suggest:
I think the short one-letter names combined into a single ‘-’ are more readable, as I suspect do many others accustomed to their decades-long use across all Unix commands, so I suggest things stay as they are. :-)
The added benefit is that the short options are faster to search for in the man page.
Just to let everyone know I have not sent a provocative message and gone away. -- u34
On 2022-12-13 at 10:34:59 +0000, Lukas Jirkovsky <l.jirkovsky@gmail.com> wrote:
On Tue, 13 Dec 2022 at 07:25, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
Hi u34,
I think long command line options are more readable compared to short one. There fore, I suggest:
I think the short one-letter names combined into a single ‘-’ are more readable, as I suspect do many others accustomed to their decades-long use across all Unix commands, so I suggest things stay as they are. :-)
For commands and options I've been using for decades, absolutely. For newer or lesser used commands, or commands with newer options, well, maybe. Now who told tar and ps that they don't need the dash? ;-)
The added benefit is that the short options are faster to search for in the man page.
Unless there's --long-option and --other-option, in which case searching for -o takes longer. And searching for various regular expressions that fail on various man pages definitely takes even more longerer™. TL;DR: I'm usually in favor of using long options in a script (those decades-old commands and options notwithstanding). Without the man page, I have some chance of figuring out what --use-regular-expressions does, but less of spotting the "e" (and figuring out what it does) in the middle of -loser.
Hi,
well, maybe.
My point was to show it's subjective.
Now who told tar and ps that they don't need the dash? ;-)
Someone who created the dash to show the argument contained optional options rather than a filename. If they're not optional then the dash isn't required. :-) -- Cheers, Ralph.
On 2022-12-13 at 17:56:45 +0000, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
well, maybe.
My point was to show it's subjective.
Fair enough. On that we agree.
Now who told tar and ps that they don't need the dash? ;-)
Someone who created the dash to show the argument contained optional options rather than a filename. If they're not optional then the dash isn't required. :-)
I'll give that to you for tar, but the options are ps are, in fact, optional.
Hi,
Now who told tar and ps that they don't need the dash? ;-)
Someone who created the dash to show the argument contained optional options rather than a filename. If they're not optional then the dash isn't required. :-)
I'll give that to you for tar, but the options are ps are, in fact, optional.
True. So I should have said the dash is distinguish options from possible following arguments which would otherwise look like options. Depending on the ps(1), either all its arguments are options or their values, or process IDs are also allowed and since no dash-less option starts with a digit it can't be confused. -- Cheers, Ralph.
On Tue, 13 Dec 2022 12:43:28 -0500, 2QdxY4RzWzUUiLuE@potatochowder.com
... Unless there's --long-option and --other-option, in which case searching for -o takes longer.
Side note: I usually search for ` -o` to avoid that. The double space is so that it doesn't match -o in the middle of a sentence. But, I'm also in favor of long option names in scripts. Merlin -- Merlin Büge
2QdxY4RzWzUUiLuE@potatochowder.com wrote:
Now who told tar and ps that they don't need the dash? ;-)
probably you didn't *really* want a history lesson (which i'm not *really* qualified to give), but in the 1980s there was an effort to standardize all this. earlier commands had, or hadn't, used a dash. dashes were now considered a requirement. but, there would have been a grandfather clause for, e.g., ps, tar, and friends. slightly later, but still, i think, in the 1980s, long options were standardized to use two dashes. but, again, grandfathered in were no dashes (like dd), one dash (like [n]mh). on the main subject, but still historical, i am reminded of the arguments we had about GUI versus command line interfaces for actual computer operators (tapes, disk drives, print out, card readers, etc.). for novice operators, or even experienced operators using rare commands, a GUI was desirable. for experienced operators doing the same thing over and over again, the command line. (sadly, i don't see the relevance here!) cheers, Greg
On 2022-12-14 at 06:02:58 +0300, Greg Minshall <minshall@umich.edu> wrote:
2QdxY4RzWzUUiLuE@potatochowder.com wrote:
Now who told tar and ps that they don't need the dash? ;-)
probably you didn't *really* want a history lesson (which i'm not *really* qualified to give), but in the 1980s there was an effort to standardize all this. earlier commands had, or hadn't, used a dash. dashes were now considered a requirement. but, there would have been a grandfather clause for, e.g., ps, tar, and friends.
IIRC, SystemV ps required a dash (which is why I type "ps -ef"), but BSD ps didn't/doesn't (which is why I still type "ps -auxww").
slightly later, but still, i think, in the 1980s, long options were standardized to use two dashes. but, again, grandfathered in were no dashes (like dd), one dash (like [n]mh).
Long options are *not* standardized, at least not in the sense that there's a specification from which to write a parser.⁰ Certain specific options are pervasive (e.g., --verbose) and enshrined in GNU guidelines.¹
on the main subject, but still historical, i am reminded of the arguments we had about GUI versus command line interfaces for actual computer operators (tapes, disk drives, print out, card readers, etc.). for novice operators, or even experienced operators using rare commands, a GUI was desirable. for experienced operators doing the same thing over and over again, the command line. (sadly, i don't see the relevance here!)
Old xterm man pages contained the "bug" that most commands hadn't been rewritten for X11. And here we are, four decades later, inventing all manner of kluges to automate and/or script GUIs (and don't even get me started on the WWW). :-) Apple's AU/X had (I don't use MacOS X now) a thing called Commando, which turned a machine-readable description of a program's command line arguments into a dialong box, a sort of "best of both worlds" solution. ⁰ https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html ¹ https://www.gnu.org/prep/standards/standards.html
participants (7)
-
2QdxY4RzWzUUiLuE＠potatochowder.com
-
Greg Minshall
-
Lukas Jirkovsky
-
Merlin Büge
-
Ralph Corderoy
-
u34＠net9.ga
-
Óscar García Amor