e-letter wrote: > I wrote 'xyz' not as literal, verbatim encoded text but as an example.
But your example displayed the output from base64 that corresponded exactly to literally giving it "xyz" as input. We only know what you are doing from the data you show us. Therefore literal and verbatim is important to avoid miscommunication. > Repeating this as follows causes the same error: > > ...@localhost ~]$ base64 -d Zm9vCg== > base64: Zm9vCg==: No such file or directory > > > $ echo foo | base64 > > Zm9vCg== > > > > $ echo foo | base64 | base64 -d > > foo > > > > $ echo Zm9vCg== | base64 -d > > foo > > > > This occurs, but is not explained in the manual. The manual clearly > states that the option is to be entered before the file/standard > input. You seem to be confused or misunderstanding about the concept of standard input. Let me try to explain this concept. Standard input (or also known as stdin) isn't a string on the command line. [Although using echo and printf strings on the command line can be written as standard output (aka stdout) from one program and connected by a pipe to the stdin of another.] Nor is standard output a file on the command line. Stdin is data read from the standard input stream. Perhaps this reference will do a better job of explaining this than I will: http://en.wikipedia.org/wiki/Standard_streams The command syntax synopsis is: base64 [OPTION]... [FILE] You are trying: > ...@localhost ~]$ base64 -d Zm9vCg== > base64: Zm9vCg==: No such file or directory When you say "-d" that is parsed as an option. It starts with a dash and corresponds to a valid option. Operate as a decoder. The remaining option argument string is "Zm9vCg==". Not starting with a dash it is not an option argument. That string appears in the [FILE] position. The syntax synopsis shows that if there is a non-option argument then the only valid strings there must be the named files on disk. The program attempts to read the named file. This operation fails and is reported. This is standard behavior for all programs and is not something particular to base64. Look at the 'cat' command syntax synopsis for another example. Everything we have said here could also be said about the cat command. In fact I would suggest using cat as your illustrative example until everything becomes clear since it is simpler and universally known and understood. The base64 command reads from named files specified as file option arguments or if none are specified it will read from standard input. That is the significance of the brackets [...] as the brackets show that the file name argument is optional. If you want to read from stdin then do not specify any file option arguments and provide the data in stdin. To try to remove the confusion let's try a different syntax synopsis. Let's look at mkdir. mkdir [OPTION]... NAME... That syntax synopsis specifies that mkdir may have option arguments. Then it specifies that it *must* have a file name argument. It specifies this by not including brackets. Because NAME does not include brackets around it that specifies that it is not optional. The mkdir command must have a filename on the command line. It is not optional. Hope this further explanation helps. Bob
