Subject: bin/2688: [dM] ps can display tty names ps -t doesn't like
To: None <gnats-bugs@NetBSD.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: netbsd-bugs
Date: 08/12/1996 11:21:15
>Number:         2688
>Category:       bin
>Synopsis:       [dM] ps can display tty names ps -t doesn't like
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Aug 12 11:50:02 1996
>Last-Modified:
>Originator:     der Mouse
>Organization:
	Dis-
>Release:        $NetBSD: ps.c,v 1.15 1995/05/18 20:33:25 mycroft Exp $
>Environment:
	Noticed on SPARC IPC and Sun-3/260.
>Description:
	ps can display tty names that ps -t doesn't accept.  For
	example, on a modern NetBSD/sun3 machine, logging in to the
	framebuffer puts you on /dev/kd, and ps displays "kd" in the
	"TT" column.  But "ps atkd" complains that it can't find
	/dev/ttykd!

	Furthermore, ps has traditionally allowed selecting "no tty"
	with "ps at\?".  Neither that nor "ps at\?\?" (because ps
	displays "??" under "TT", instead of the traditional "?") works
	for this.

	UTSLing reveals that the -t option special-cases "co" and
	demands that anything else be either a full pathname or
	something that can be concatenated onto /dev/tty (well,
	_PATH_TTY).  I contend that it should accept anything that ps
	would print in the TT column.  Symlinking /dev/ttykd->kd
	"cures" the problem for "ps atkd" on the sun3, but there
	appears to be no way at all to get the effect of traditional
	"ps at\?".
>How-To-Repeat:
	Log in on /dev/kd, run ps, see "kd", try "ps atkd", get a
	confusing error.  Try to display all and only processes that
	would be listed with a ?? in the TT column, find there is no
	way to do that.
>Fix:
	A first cut at a fix for the non-?? problem might be to change

			if (strcmp(optarg, "co") == 0)
				ttypath = _PATH_CONSOLE;
			else if (*optarg != '/')
				(void)snprintf(ttypath = pathbuf,
				    sizeof(pathbuf), "%s%s", _PATH_TTY,
				    optarg);
			else
				ttypath = optarg;
			if (stat(ttypath, &sb) == -1)
				err(1, "%s", ttypath);

	to something more like

		if (arg is "co")
			use _PATH_CONSOLE
		else if (arg begins with /)
			use it unchanged
		else
			try %s%s,_PATH_TTY,arg
			if stat fails, try /dev/%s,arg
			if stat still fails, error
			otherwise use the one that statted successfully

	I'd send diffs, but fixing the ?? problem may mean completely
	redesigning the way ps -t works.  If this PR just sits for a
	while I may end up doing that, but I'm hoping someone will have
	a _good_ fix, or at least some suggestions.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu
		    01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D
>Audit-Trail:
>Unformatted: