|Anonymous | Login||2022-01-20 07:25 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001544||[1003.1(2016/18)/Issue7+TC2] Shell and Utilities||Editorial||Clarification Requested||2022-01-08 03:21||2022-01-11 00:19|
|Name||Christoph Anton Mitterer|
|Final Accepted Text|
|Summary||0001544: uudecode: standardise or at least reserve - as another special symbol for decoding to stdout|
As of now:
doesn’t specify "-" as a special symbol for the -o option in order to print the decoded output to stdout, but only the special symbol '/dev/stdout'
The rationale even explains:
In early drafts, the [ -o outfile] option-argument allowed the use of - to mean standard output. The symbol - has only been used previously in POSIX.1-2017 as a standard input indicator. The standard developers did not wish to overload the meaning of - in this manner. The /dev/stdout concept exists on most modern systems. The /dev/stdout syntax does not refer to a new special file. It is just a magic cookie to specify standard output.
The problem with that is that there is no strict guarantee that this file really exists or is available to the process.
Imagine a chrooted process where /dev/ and /proc are not bind-mounted or take e.g. Debian's initramfs, where at least as of now, /dev/stdout doesn't exist as a file.
IMO, the decision to use a file name as special symbol was rather unfortunate if not short sighted.
I've seen at least one implementation which did not support '/dev/stdout' (as a special symbol until recently (busybox, and even now it depends on build configuration so it's not guaranteed to work).
This can of course have the effect that output that should go to stdout, goes actually to a file /dev/stdout, if the implementation "forgot" about that speciality of POSIX, and the file doesn't exist as "special file" that also causes output to stdout.
The problem is that this could of course cause leakage of sensitive data.
At least GNU's uudecode and busybox' unconditionally support "-" as special symbol for -o.
It may make sense to reserve "-" as well for that purpose (i.e. that conforming applications must not use it as literal filename).... or even directly standardise it as such (i.e. that conforming implementations need to support it)).
Of course this may break compatibility if anyone really used it in the sense of a actual filename.
Alternatively a new option could be standardised, overriding -o and meaning write to stdout.
I think POSIX should at least reserve
|Tags||No tags attached.|
It's odd that uudecode is required to treat a pathname of "-" encoded in the input file as meaning standard output (see STDOUT) but is not allowed to do so when the same pathname is specified with "-o -".
Solaris and macOS both create a file named "-" when "-o -" is specified, so the suggestion of disallowing this is unlikely to achieve consensus.
I think the best we can do for now is to make it unspecified whether "-o -" means standard output or a file named "-", perhaps with an entry under FUTURE DIRECTIONS saying a future version may require it to mean standard output.
Incidentally, the rationale is no longer correct when it says "The symbol - has only been used previously in POSIX.1-2017 as a standard input indicator", since the STDOUT section for uniq was changed in Issue 7 to say it is allowed to treat an output_file operand of "-" as meaning standard output.
It would be a very very tiny step forward... but at least something.
OTOH, also Solaris/macOS would likely benefit from a more strict standardisation:
I guess it's more likely that code from a platform (typically Linux / GNU) that blindly assumes "-" to be stdout is used on their side (and thus produce unexpected results) than the other way round.
Are any people from Solaris / macOS involved here? Maybe one could just ask if these guys would be willing to adapt.
Oracle Solaris no longer formally participates in the standard committee, though a few developers like myself maintain an informal interest.
I cannot officially speak on behalf of Oracle, but we are generally willing to consider improving Solaris compatibility with Linux & BSD systems where it makes sense and doesn't break existing customer usage, but that would only help those who update their systems, not those using older releases.
|2022-01-08 03:21||calestyo||New Issue|
|2022-01-08 03:21||calestyo||Name||=> Christoph Anton Mitterer|
|2022-01-08 03:21||calestyo||Section||=> uudecode|
|2022-01-08 03:21||calestyo||Page Number||=> N/A|
|2022-01-08 03:21||calestyo||Line Number||=> N/A|
|2022-01-10 10:08||geoffclare||Note Added: 0005584|
|2022-01-10 15:16||calestyo||Note Added: 0005586|
|2022-01-11 00:19||alanc||Note Added: 0005592|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|