Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
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
Reporter calestyo View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Christoph Anton Mitterer
User Reference
Section uudecode
Page Number N/A
Line Number N/A
Interp Status ---
Final Accepted Text
Summary 0001544: uudecode: standardise or at least reserve - as another special symbol for decoding to stdout
Description 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.
Desired Action 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.
Attached Files

- Relationships

-  Notes
geoffclare (manager)
2022-01-10 10:08

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.
calestyo (reporter)
2022-01-10 15:16

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.
alanc (reporter)
2022-01-11 00:19

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.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker