# # logname, pipes and controlling terminals
APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

logname, pipes and controlling terminals

I've removed advertising from most of this site and will eventually clean up the few pages where it remains.

While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.

If you found something useful today, please consider a small donation.



Some material is very old and may be incorrect today

© March 2005 Tony Lawrence

A customer complained that many of his scripts would generate an error:


 
     logname: no login name 
 

These were scripts that had been transferred to Linux from a SCO system where they had worked without error. Upon investigation, the offense was usually due to something like:


 
    ps -e | grep `logname` 
 

The reason this fails on Linux is because it's supposed to. The logname command actually calls "getlogin":


 
  /* POSIX requires using getlogin (or equivalent code).  */ 
  cp = getlogin (); 
  if (cp) 
    { 
      puts (cp); 
      exit (EXIT_SUCCESS); 
    } 
  /* POSIX prohibits using a fallback technique.  */ 
  fprintf (stderr, _("%s: no login name\n"), argv[0]); 
  exit (EXIT_FAILURE); 
 

So why doesn't getlogin work here? Because it's on the other side of a pipe and therefore isn't associated with the controlling terminal of the process that called it. The man page for getlogin says:

 
       getlogin  returns a pointer to a string containing the
       name of the user logged in on the controlling terminal
       of the process, or a null pointer if  this  information
       cannot  be determined.
 

It's deliberate: getlogin doesn't have info for the process, so logname fails. So why does it work on SCO (and BSD and Mac OS X)? Because their getlogin is different. This is from the getlogin man page from my Mac:

 
     In earlier versions of the system, getlogin() failed
     unless the process was associated with a login terminal.
     The current implementation (using setlogin()) allows
     getlogin to succeed even when the process has no con-
     trolling terminal.  In earlier versions of the system,
     the value returned by getlogin() could not be trusted
     without checking the user ID. Portable programs should
     probably still make this check.
 

So how to you fix the problem? Well, don't use logname in this way. Instead, grep for $LOGNAME or use ps -u $LOGNAME

Annoying? Sure. But "logname" shouldn't trust things like $LOGNAME, so it probably is correct behavior.


If you found something useful today, please consider a small donation.



Got something to add? Send me email.





(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

->
-> logname, pipes and controlling terminals


Inexpensive and informative Apple related e-books:

Photos: A Take Control Crash Course

Take Control of OS X Server

Take Control of IOS 11

Are Your Bits Flipped?

Take Control of iCloud





More Articles by © Tony Lawrence





Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us


Printer Friendly Version





Any sufficiently advanced technology is indistinguishable from magic. (Arthur C Clarke)




Linux posts

Troubleshooting posts


This post tagged:

Forum

Linux

Programming

Scripting

Shell

Unix



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode