Re: why is grep behaving this way ?

[cga2000 <cga2000@optonline.net>]

On Fri, Mar 02, 2007 at 04:37:37AM EST, Bhasker C V wrote:
>    I have logname command give me this output
>    [bhaskerv@cvsrep01 ~]$ logname
>    bhaskerv
> 
>    and say i execute this command
> 
>    [bhaskerv@cvsrep01 ~]$ echo `logname`
>    bhaskerv
> 
>    till this it is all fine
> 
>    BUT
>    [bhaskerv@cvsrep01 ~]$ who | grep `logname`
>    logname: no login name
>    Usage: grep [OPTION]... PATTERN [FILE]...
>    Try `grep --help' for more information.
> 
>    is there anything i am doing wrong ?

bash man page:

  "Each command in a pipeline is executed as a separate process (i.e.,
   in a subshell)."

The problem appears to be that the subshell where `logname` executes is
not a login shell.

Here are a few commands I issued from the linux console that may help
clarify:

$ logname
  myuser

$ logname 1>&2 | logname             # redirect stdout to stderr
  myuser                             # 1st instance of logname
  logname: no login name             # 2nd instance of logname

The 1st logname command is successful. 

The 2nd logname command executes in a subshell and returns the message
you reported.

$ logname | logname 2> /dev/null      # returns nothing

The 2nd instance of logname writes an error message to stderr and
nothing to stdout.

As a result,

$ who | grep `logname`

ends up as:

$ who | grep

.. resulting in a syntax error.

Another angle of approach is that the logname command can only return
the login name as long as the calling process added an entry to the utmp
file (see info coreutils logname) .. If not, it fails and displays the
"logname: no login name" message.  I guess it would not make much sense
having all subshells invoked during an interactive session create/remove
entries to/from the /var/run/utmp file.

Thanks,
cga