Re: base64 terminal input failure

[Bob Proulx]

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