Using less in environment without controlling tty

Harald Becker ralda at gmx.de
Sun Aug 4 22:12:36 UTC 2013


Hi Denys !

>>>Then try:
>>>cmd | setsid sh -c 'exec >/dev/tty12 2>&1 ; exec less'
>>
>> NO! ... the cmd itself does fork, exec sh -c COMMAND, and pipe
>> the data into stdin of the forked COMMAND. That is, after fork
>> the first program is sh, so you can't use setsid as part of the
>> COMMAND you give.
>
>I didn't understand this explanation.

'cmd' is a program which forks and exec sh -c COMMAND, where
COMMAND is a string send to that program.

so if I send the command "setsid; exec ..." to my program, it
does:

output of 'cmd' | sh -c 'setsid; exec ...'

and NOT as you mentioned:

cmd | setsid sh -c 'exec ...'


>> And NO again! I do not want to create a controlling tty for
>> less!
>
>Controlling tty concept exists for a reason.
>It is a tty which has some control over the process in question.
>
>You don't want to have a controlling tty yet you want
>to use that tty to control your process?

No that is wrong! I do not want to let the tty 'control' my
process in the sense of Unix process control. The only thinh I
want, is the tty sending key codes, which get read and
interpreted by my process. Meanwhile the process stays under
control of a different tty, that is may be interrupted or
stopped from that tty, not from the tty used to display
messages.

>I just hope tomorrow you won't refuse to use cp for copying.

Denys you are joking ... I don't want to do something curious.
I just want to display some messages on tty without getting this
tty a controlling tty, and I want to display those messages with
a program designed to show messages on a tty.


>> I just want to use less a given tty without this tty becoming a
>> controlling tty. As it is possible with standard less.
>
>A less on Fedora 18 (less --version says:
>less 444
>Copyright (C) 1984-2009 Mark Nudelman)
>does NOT handle "less FILE 1<>/dev/ttyFOO" well.

Whops ... sounds bad, the last versions of less I used for this
purpose where anywhere around version number 390. Looks like
something changed ... and yes, now they do open /dev/tty :(

... and lost the flexibility of the older versions ... very sad.


>Even Q doesn't work. And, of course, ^C doesn't either
>(ttyFOO isn't a ctty!).

^C shall not work, it still works on your original controlling
tty. ttyFOO shall not send any signals to any process.

>> I gave a possible solution for my request, but did not get any
>> response on this yet.
>
>I'm adding support for trying ttyname(2), but if that
>doesn't work for you (say, if you have no /proc mounted),
>then that's it.

Denys, my approach is minimal intrusive and allows for all use
cases. Why do you want to change that. The difference is tty
from stdout, not stderr. Else it does exactly behave as before
on /dev/tty ... with a fallback of directly using stdout, only if
the open of the tty (either ttyname or /dev/tty) fails. Standard
less (current version 460) does here fallback to fd 2 (stderr),
but doesn't check if it is a tty. Where stdout is tested to be a
tty, so I consider stdout to be a better fallback. May be you
like to stay with stderr as fallback?

The isatty(3) is a simple approach to allow giving a different
tty to less, like you suggested 'less --tty'. I do not fiddle
with command options, just test if a tty is provided on fd 3, and
use that if true. 

I appended a patch for this ...

If you do not like that fd 3 approach, just comment the line with
the "if (!isatty(kb_fd=3))". The remaining code opens a tty on
same device as stdout is assigned (ttyname) or use /dev/tty.

--
Harald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: less.c.patch
Type: text/x-patch
Size: 469 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20130805/9840f342/attachment-0001.bin>


More information about the busybox mailing list