• Please review our updated Terms and Rules here

Hidden feature of login command

Elektraglide

Experienced Member
Joined
Mar 24, 2023
Messages
53
Location
UK
While reverse engineering various commands on the Tektronix 4404 I came across code in the login command that does a check equivalent to:

Code:
if (!strcmp(argv[0], "su"))
behave like substitute user

ie if the login command is named "su" it behave differently. So I created a link called su to login and sure enough it does do what it says on the can. Neat!

Is that a common feechur on other systems?
 
It is not unsurprising.

The su command means to (effectively) switch to a new user (from your login) as a super user.

So, I would have thought, most of the code would be similar to the login command - just slightly different - as evidenced by the bulk of common and some conditional code within the same executable.

Dave
 
Unix has always passed the command name that the user typed to the program as argv[0] and, as you've seen, the program can change its behaviour based on that value. This is a very common technique (it saves on binary space since all the "different" programs are just differently-named links to a single file, and has been available in Unixen since the 70s. Two examples from 7th Edition Unix in 1979 are seen in mail (also called as rmail) and sh (also called as rsh).

It's still used today in userlands designed for embedded systems, where all of the userland programs are one single large binary that dispatches on the name under which it's called. (This effectively lets all programs share one copy of the libraries without having to have the expense and overhead of shared libraries.)

But entirely undocumented! :)
Well, where would you document it? It's just sort of an obvious (once you hear or think of it) thing that falls out from argv[0] being the program name and hard links being available.

I don't think there's ever been official documentation that XRA A / xor a,a is the canonical way of writing MVI A,0 / ld a,0 on the 8080/Z80, either, except perhaps in beginners' books. It's something people just figure out from first principles and then the knowledge of it spreads.
 
I don't think there's ever been official documentation that XRA A / xor a,a is the canonical way of writing MVI A,0 / ld a,0 on the 8080/Z80, either, except perhaps in beginners' books. It's something people just figure out from first principles and then the knowledge of it spreads.
But it isn't--XRA A will change the flags register. MVI/LD will not. That can matter a lot.
 
But it isn't--XRA A will change the flags register. MVI/LD will not. That can matter a lot.
I was speaking from the perspective of someone coming to 8080 after first having learned 6502 and 6800, where LDA #0 also changes the flags register. And yes, on 8080 it can matter a lot, but far more often it doesn't.

(I've looked at a fair amount of 8080/Z80 source code, particularly ROM BIOSes, and ld a,0 is rarely seen. There are four uses in the TRS-80 Model I Level II 1.2 ROM, versus 62 of xor a. There are 9 ld a,0 in the PC-8001 ROM, vs. 133 xor a. So about 6-7% in both cases, and I've not actually checked these to see if any of the ld can be replaced with xor.)
 
Depends on the programmer and skill. There are times when not modifying the flags register is important. There are lots of little gotchas in all architectures. For example, INX and DCX on the 8080/8085 are not handled by the ALU, so modify no flags.
 
Depends on the programmer and skill. There are times when not modifying the flags register is important. There are lots of little gotchas in all architectures. For example, INX and DCX on the 8080/8085 are not handled by the ALU, so modify no flags.
I really wasn't looking to bring up things like this with my example; perhaps you can suggest a different example or parallel that makes my original point that does not spawn a huge discussion about the intricacies of how flags work in 8080 processors?
 
...

ie if the login command is named "su" it behave differently. So I created a link called su to login and sure enough it does do what it says on the can. Neat!

Is that a common feechur on other systems?
Yes. Embedded systems will often use the 'busybox' software, which is a full but minimal set of Unixish utilities all in one executable, where argv[0] is used to select the behavior. Busybox is used in a vast number of places, including network cameras, routers, network video recorders, basically anywhere you need those utilities with a minimal memory footprint.
 
Okay, how about this...

ORA A vs.
ANA A vs.
CMP A

For testing the content of the A register.
So you would say that's undocumented in the same sense that the "multiple links to one inode containing a program that adjusts behaviour based on argv[0]" is undocumented. I kinda feel like the Intel and Zilog manuals are pretty clear about what flags are affected and how by each of those three instructions. What's the thing you do with those that's not in the documentation, in the way that the documentation for xor does not point out that xor a,a loads a with 0?

(To be clear, it was eventually added to at least some Intel documentation: the 8085 manual mentions this. But the 8080 manual did not.)
 
Last edited:
One uses the hardware, taking cum grano salis anything in the published manuals. Surely you understand that by now. One gets used to it.
I don't really understand where you're trying to go with this. You clearly didn't like the parallel I was trying to draw, since you spend several posts quibbling with it; all I'm asking for is a different parallel that you think is accurate enough to my original point that you won't spend yet more messages quibbling with it. How does anything in the last four messages you've posted relate to documentation (or lack thereof) of using argv[0] to distinguish multiple links to an executable?
 
Just so. Intel could have assigned a new "TEST A" mnemonic to any of the above, just as they assigned NOP to XCHG AX,AX on the 8086 (originally). The wonderful thing about the 8080 is that there are so many NOP instructions.
 
ORA A vs.
ANA A vs.
CMP A
For testing the content of the A register.
It's really personal preference...
Well, personal preference like JMP vs CALL is personal preference. Those three instructions do not all do the same thing. (CMP has vastly different effect on the flags from the other two; remember that CMP is a SUB that throws away the result of the subtraction instead of putting it in the A register.)

, though I can't ever recall CP A being used for that purpose, only OR A and AND A.
The reason would be you can't use CMP A for the same purposes as ORA A and ANA A.
 
I tossed in the CMP A as a red herring. It's a convenient way to set the zero bit in the flags register without affecting any data register contents. What I said about level of expertise.
 
Back
Top