What file display command does NOT default to STDIN if unspecified? - Unix

This is a discussion on What file display command does NOT default to STDIN if unspecified? - Unix ; I'm looking for a command to display the contents of a file, which takes the filename as an arg, and which fails if the arg isn't given or the file doesn't exist. The problem with cat, tail, head, grep, and ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: What file display command does NOT default to STDIN if unspecified?

  1. What file display command does NOT default to STDIN if unspecified?

    I'm looking for a command to display the contents of a file, which
    takes the filename as an arg, and which fails if the arg isn't given
    or the file doesn't exist.

    The problem with cat, tail, head, grep, and so forth is that if you
    supply no argument, it defaults to STDIN. This causes us trouble
    from time to time in shell scripts because someone will use the idiom
    myValue=`cat $VALUE_FILE` expecting that VALUE_FILE would have been
    set in the environment. But if not, then of course the cat command
    defaults to STDIN and sits there waiting for input.

    Searched around the groups already and the results overwhelmingly deal
    with "cat", so it's a bit hard to sift through. Help appreciated.


  2. Re: What file display command does NOT default to STDIN if unspecified?

    thecrow wrote:
    > I'm looking for a command to display the contents of a file, which
    > takes the filename as an arg, and which fails if the arg isn't given
    > or the file doesn't exist.
    >
    > The problem with cat, tail, head, grep, and so forth is that if you
    > supply no argument, it defaults to STDIN. This causes us trouble
    > from time to time in shell scripts because someone will use the idiom
    > myValue=`cat $VALUE_FILE` expecting that VALUE_FILE would have been
    > set in the environment. But if not, then of course the cat command
    > defaults to STDIN and sits there waiting for input.


    That's because you aren't quoting your variable as you should:

    $ myValue=`cat $VALUE_FILE`

    $ myValue=`cat "$VALUE_FILE"`
    cat: : No such file or directory

    > Searched around the groups already and the results overwhelmingly deal
    > with "cat", so it's a bit hard to sift through. Help appreciated.
    >


    Ed.

  3. Re: What file display command does NOT default to STDIN if unspecified?

    On Apr 21, 12:46 pm, Ed Morton wrote:
    > thecrow wrote:
    > > I'm looking for a command to display the contents of a file, which
    > > takes the filename as an arg, and which fails if the arg isn't given
    > > or the file doesn't exist.

    >
    > > The problem with cat, tail, head, grep, and so forth is that if you
    > > supply no argument, it defaults to STDIN. This causes us trouble
    > > from time to time in shell scripts because someone will use the idiom
    > > myValue=`cat $VALUE_FILE` expecting that VALUE_FILE would have been
    > > set in the environment. But if not, then of course the cat command
    > > defaults to STDIN and sits there waiting for input.

    >
    > That's because you aren't quoting your variable as you should:
    >
    > $ myValue=`cat $VALUE_FILE`
    >
    > $ myValue=`cat "$VALUE_FILE"`
    > cat: : No such file or directory


    Well, that's somewhat useful, but is it realistic? I consider that
    defensive coding against a scenario that should be altogether
    avoided. I could go edit all these scripts to add defensive quotes,
    but really, who quotes everyting in a shell script? Somewhere down
    the line, some ignorant maintainer could come behind me and delete
    them, not being aware of their importance. If there were some
    command other than cat, then that might signal more strongly the
    intentions to future maintainers, more so than just using quotes.
    (And I don't believe in comments unless there's no way at all to make
    the code so obvious as to be self-documenting)


  4. Re: What file display command does NOT default to STDIN if unspecified?

    On 2007-04-22, thecrow wrote:
    > On Apr 21, 12:46 pm, Ed Morton wrote:
    >> thecrow wrote:
    >> > I'm looking for a command to display the contents of a file, which
    >> > takes the filename as an arg, and which fails if the arg isn't given
    >> > or the file doesn't exist.

    >>
    >> > The problem with cat, tail, head, grep, and so forth is that if you
    >> > supply no argument, it defaults to STDIN. This causes us trouble
    >> > from time to time in shell scripts because someone will use the idiom
    >> > myValue=`cat $VALUE_FILE` expecting that VALUE_FILE would have been
    >> > set in the environment. But if not, then of course the cat command
    >> > defaults to STDIN and sits there waiting for input.

    >>
    >> That's because you aren't quoting your variable as you should:
    >>
    >> $ myValue=`cat $VALUE_FILE`
    >>
    >> $ myValue=`cat "$VALUE_FILE"`
    >> cat: : No such file or directory

    >
    > Well, that's somewhat useful, but is it realistic?


    Absolutely! Also essential.

    > I consider that defensive coding against a scenario that should be
    > altogether avoided.


    The rot has set in to such a degree that it cannot be avoided. Are
    there still any systems without any filenames containing spaces?

    > I could go edit all these scripts to add defensive quotes, but
    > really, who quotes everyting in a shell script?


    Defensive coders.

    > Somewhere down the line, some ignorant maintainer could come behind
    > me and delete them, not being aware of their importance.


    Then don't hire ignorant maintainers.

    > If there were some command other than cat, then that might signal
    > more strongly the intentions to future maintainers, more so than
    > just using quotes.


    Write one. It can be a wrapper to cat, if you like.

    > (And I don't believe in comments unless there's no way at all to
    > make the code so obvious as to be self-documenting)


    Dream on!

    --
    Chris F.A. Johnson, author |
    Shell Scripting Recipes: | My code in this post, if any,
    A Problem-Solution Approach | is released under the
    2005, Apress | GNU General Public Licence

  5. Re: What file display command does NOT default to STDIN if unspecified?

    On Apr 21, 10:39 pm, "Chris F.A. Johnson"
    wrote:
    > On 2007-04-22, thecrow wrote:
    > > On Apr 21, 12:46 pm, Ed Morton wrote:
    > >> thecrow wrote:
    > >> > I'm looking for a command to display the contents of a file, which
    > >> > takes the filename as an arg, and which fails if the arg isn't given
    > >> > or the file doesn't exist.

    >
    > >> > The problem with cat, tail, head, grep, and so forth is that if you
    > >> > supply no argument, it defaults to STDIN. This causes us trouble
    > >> > from time to time in shell scripts because someone will use the idiom
    > >> > myValue=`cat $VALUE_FILE` expecting that VALUE_FILE would have been
    > >> > set in the environment. But if not, then of course the cat command
    > >> > defaults to STDIN and sits there waiting for input.

    >
    > >> That's because you aren't quoting your variable as you should:

    >
    > >> $ myValue=`cat $VALUE_FILE`
    > >>
    > >> $ myValue=`cat "$VALUE_FILE"`
    > >> cat: : No such file or directory

    >
    > > Well, that's somewhat useful, but is it realistic?

    >
    > Absolutely! Also essential.


    It's not essential. Essential would mean you can't live without it.
    Most shell code will work just fine without quoting each and every
    variable. I can show you thousands of lines of code that don't quote
    each and every variable, and go years without failure. A very good
    practice, yes. Essential, no.

    >
    > > I consider that defensive coding against a scenario that should be
    > > altogether avoided.

    >
    > The rot has set in to such a degree that it cannot be avoided. Are
    > there still any systems without any filenames containing spaces?


    Being aware of them and actively employing them them are two entirely
    different things. In our system at least (Sun-based), filenames
    without spaces simply don't exist.

    > > Somewhere down the line, some ignorant maintainer could come behind
    > > me and delete them, not being aware of their importance.

    >
    > Then don't hire ignorant maintainers.


    Yes, all I need to do is either promote myself to director so I have
    hire/fire authority, and then travel back in time and not hire the
    ones we already have working. That's a useful suggestion.

    > > If there were some command other than cat, then that might signal
    > > more strongly the intentions to future maintainers, more so than
    > > just using quotes.

    >
    > Write one. It can be a wrapper to cat, if you like.


    I'm looking for a command that is probably part of a standard Unix
    distribution so I can expect it to be on the server, and not have to
    manually deploy this bit of duct tape on each box.

    > > (And I don't believe in comments unless there's no way at all to
    > > make the code so obvious as to be self-documenting)

    >
    > Dream on!


    What does this comment mean, that you consider it impossible to write
    clear code, or that commenting is a maintainable way of describing
    your program's intent? Comments lie because they never get
    maintained.



  6. Re: What file display command does NOT default to STDIN if unspecified?

    * thecrow [2007.04.22 02:29]:
    > (And I don't believe in comments unless there's no way at
    > all to make the code so obvious as to be self-documenting)


    You mean like this:

    [ -n "$VALUE_FILE" ] && myValue=$(cat "$VALUE_FILE")

    or to be even more explicit about it:

    if [ -n "$VALUE_FILE" ] ; then
    myValue=$(cat "$VALUE_FILE")
    else
    printf "Error: undefined variable\n" 1>&2
    if

    --
    JR

  7. Re: What file display command does NOT default to STDIN if unspecified?

    * Jean-Rene David [2007.04.22 14:37]:
    > * thecrow [2007.04.22 02:29]:
    >> (And I don't believe in comments unless there's no way at
    >> all to make the code so obvious as to be self-documenting)

    >
    > You mean like this:
    >
    > [ -n "$VALUE_FILE" ] && myValue=$(cat "$VALUE_FILE")
    >
    > or to be even more explicit about it:
    >
    > if [ -n "$VALUE_FILE" ] ; then
    > myValue=$(cat "$VALUE_FILE")
    > else
    > printf "Error: undefined variable\n" 1>&2
    > if

    ^^
    fi

    Sorry.

    --
    JR

  8. Re: What file display command does NOT default to STDIN if unspecified?

    In article <1177208996.484008.48220@p77g2000hsh.googlegroups.c om>,
    thecrow wrote:

    > On Apr 21, 12:46 pm, Ed Morton wrote:
    > > thecrow wrote:
    > > > I'm looking for a command to display the contents of a file, which
    > > > takes the filename as an arg, and which fails if the arg isn't given
    > > > or the file doesn't exist.

    > >
    > > > The problem with cat, tail, head, grep, and so forth is that if you
    > > > supply no argument, it defaults to STDIN. This causes us trouble
    > > > from time to time in shell scripts because someone will use the idiom
    > > > myValue=`cat $VALUE_FILE` expecting that VALUE_FILE would have been
    > > > set in the environment. But if not, then of course the cat command
    > > > defaults to STDIN and sits there waiting for input.

    > >
    > > That's because you aren't quoting your variable as you should:
    > >
    > > $ myValue=`cat $VALUE_FILE`
    > >
    > > $ myValue=`cat "$VALUE_FILE"`
    > > cat: : No such file or directory

    >
    > Well, that's somewhat useful, but is it realistic? I consider that
    > defensive coding against a scenario that should be altogether
    > avoided. I could go edit all these scripts to add defensive quotes,
    > but really, who quotes everyting in a shell script? Somewhere down
    > the line, some ignorant maintainer could come behind me and delete
    > them, not being aware of their importance. If there were some
    > command other than cat, then that might signal more strongly the
    > intentions to future maintainers, more so than just using quotes.
    > (And I don't believe in comments unless there's no way at all to make
    > the code so obvious as to be self-documenting)


    What expectation do you have that these sloppy coders will remember to
    use this command, rather than the "cat" that they've been using for so
    many years?

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  9. Re: What file display command does NOT default to STDIN if unspecified?

    2007-04-21, 09:07(-07), thecrow:
    > I'm looking for a command to display the contents of a file, which
    > takes the filename as an arg, and which fails if the arg isn't given
    > or the file doesn't exist.
    >
    > The problem with cat, tail, head, grep, and so forth is that if you
    > supply no argument, it defaults to STDIN. This causes us trouble
    > from time to time in shell scripts because someone will use the idiom
    > myValue=`cat $VALUE_FILE` expecting that VALUE_FILE would have been
    > set in the environment. But if not, then of course the cat command
    > defaults to STDIN and sits there waiting for input.
    >
    > Searched around the groups already and the results overwhelmingly deal
    > with "cat", so it's a bit hard to sift through. Help appreciated.


    cat $VALUE_FILE

    is totally incorrect. Leaving a variable unquoted has a very
    special meaning to the shell, probably not the one you think it
    has.

    Having said that

    cat "$VALUE_FILE"

    has problems as well for instance if the file name starts with
    "-", because that's

    cat "$OPTION_OR_FILE"

    if you want just the file, that's

    cat -- "$VALUE_FILE"

    Having said that, that will still not do what you expect for a
    file called "-", as cat will take it as stdin.

    So simply, use the POSIX:

    cat < $VALUE_FILE

    Having said that,

    the above is only valid in non-interactive POSIX shells, it's
    not in bash for instance. So, I tend to use:

    cat < "$VALUE_FILE"

    The other avantage over cat -- "$VALUE_FILE" is that cat is not
    even executed if the file can't be open.


    --
    Stéphane

+ Reply to Thread