25 Sep
2017
25 Sep
'17
12:07 p.m.
Larry McVoy:
+1 on what Ron said. I don't get the rationale
for going back to ptrace.
Anyone know what it is? Is there a perf issue?
Kurt H Maier:
The usual rationale presented is that someone can exhaust the fd table
and then you can't get anything done. Instead of fixing that problem,
the popular approach is to add more syscalls, like with getrandom(2).
====
Funny that that rationale isn't extended to its logical
conclusion: get rid of open and creat. Then nobody needs
to worry about running out of file descriptors ever!
I too am saddened to see such a retrograde step, but perhaps
I'm biased. When I arrived in 1127, the kernel had /proc but
still had ptrace as well. Why? Because no one was brave enough
to wade into sdb and adb.
After a couple of years, I felt brave enough, so I did it.
Once the revised sdb and adb had propagated to all our systems,
I removed the syscall. I celebrated by physically removing
ptrace(2) from the Eighth Edition manual in the UNIX room: the
manual entry comprised two facing pages, which I glued together.
I can sympathize with FreeBSD excuse someone cited elsewhere,
that nobody used the code so it should go--I'm always in favour
of improving programs by chopping sutff out--but I think the
decision here was backwards. The proper answer would have been
to teach ps et al to use /proc, not to invent a new complex of
system calls.
I dislike how Linux has tossed information about processes and
other system-related data into the same namespace (and now that
there is /sys as well as /proc, I wonder whether it's time to
divorce them, or even to move /proc into /sys/proc), but the
general direction of moving things into the file system makes
sense. I have some qualms about adding more and more code to
the kernel that just does string processing (making the kernel
bigger and more complicated, and widening the attack surface
for bad guys), though; maybe most of that stuff belongs not in
the OS proper but in a user-mode program that reads /dev/mem
and presents as a file system.
Norman Wilson
Toronto ON
25 Sep
25 Sep
2:16 p.m.
New subject: UNIX of choice these days?
On Mon, Sep 25, 2017 at 8:07 AM, Norman Wilson <norman(a)oclsc.org> wrote:
...
I too am saddened to see such a retrograde step, but perhaps
I'm biased. When I arrived in 1127, the kernel had /proc but
still had ptrace as well. Why? Because no one was brave enough
to wade into sdb and adb.
...
I can sympathize with FreeBSD excuse someone cited elsewhere,
that nobody used the code so it should go--I'm always in favour
of improving programs by chopping sutff out--but I think the
decision here was backwards. The proper answer would have been
to teach ps et al to use /proc, not to invent a new complex of
system calls.
+1 that was my point. If the application code had been available @ UCB
earlier before the proliferation,
I think and /proc has been part of 4.2 or at least 4.3 not 4.4, I think
there would have been a better chance
of it being used.
I also agree about garbage collection, but this is a case where the right
solution would have been to try to get people to use the new interface.
The problem was ptrace was 'good enough' and there was no incentive so no
one did it.
Mark Litton's thesis was DBX which was being written when 4.2 was being
developed. If Mark had had /proc the simplicity would have been
compelling. But once the code was written, it was hard to justify
switching.
It's my same observation about why Fortran still is #1 in the high end of
the business. It's just not interesting to replace it.
So what I'm asking us to try to do, is not just look at the technology in a
vacuum. Why was it not interesting to /proc for BSD. Clearly, Linux
added it (differently than Eighth Edition of course and the 4.4
implementation was much more like V8 that Linux would settle). People did
do the work to use it.
So why did *BSD not bring those versions of the utilities back?
My >>guess<< while they had added some things (like /proc) it was different
again and we got into the BSD != Linux stuff - which has been the UNIX war
all over again.
Sigh....
I dislike how Linux has tossed information about processes and
other system-related data into the same namespace (and now that
there is /sys as well as /proc, I wonder whether it's time to
divorce them, or even to move /proc into /sys/proc), but the
general direction of moving things into the file system makes
sense.
I agree, but let's just create a /sys/proc namespace and try to be
consistent. Here is a case where I wish *BSD would just pick up the Linux
solution and be done with it. It's not worth arguing.,
I have some qualms about adding more and more code to
the kernel that just does string processing (making the kernel
bigger and more complicated, and widening the attack surface
for bad guys),
+1
though; maybe most of that stuff belongs not in
the OS proper but in a user-mode program that reads /dev/mem
and presents as a file system.
Agree although, I would love to see consistency and moving towards one
namespace & associated API that we all used.
3:13 p.m.
New subject: UNIX of choice these days?
On Mon, Sep 25, 2017 at 8:16 AM, Clem Cole <clemc(a)ccc.com> wrote:
The Linux solution has two barriers to entry though: GPL means the code
can't be shared and even if it could the radically different structures of
the kernel means little could be shared. So it would be, at best a
compatible implementation. There's bits of /proc for linux in the FreeBSD
Linux execution environment, but not the full thing.
On Mon, Sep 25, 2017 at 8:07 AM, Norman Wilson <norman(a)oclsc.org> wrote:
In the case of procfs and FreeBSD, the issues were more complicated and
nuanced. The original /proc code came from 4.4BSD, and interacted with a
number of kernel subsystems. These subsystems were undergoing evolution at
the time (including a rather concerted rewrite of the VM to unify the
buffer cache). This churn there lead to inevitable changes being needed to
procfs to keep up with the new interfaces and such. Over time, there grew
the feeling that there some something quite wrong with procfs (rightly or
wrongly). There was a belief there were a number of unanticipated security
issues that were lingering in the code, but due to the changes not only in
API to the other sub-systems, but also in semantics. Kernel hackers that
studied the problem came away with an uneasy feeling, but nothing
actionable. This was the back-drop that slowed its adoption into new
utilities in the FreeBSD tree and kept people from wanting to push it
further until these misgivings could be explored and addressed. In the end,
it was easier to have a better understood code base (ptrace) that had an
icky interface over one that was cleaner, but that had clouds over it. As
fewer and fewer things used /proc, it became easier and easier to ignore,
and at some point people started worrying that this code that was basically
unused could be an attack vector on the systems, so it was retired.
It's been a number of years since all this went down, so my memory of it
may be clouded. Plus, I was FreeBSD's security officer for a time, and I'm
purposely not going back to my notes from the time since I promised to keep
all that business confidential (and I'm not exactly sure where they are).
So, there may be the odd detail wrong, or imprecision of language, but the
main thrust is there: new with issues that are hard to quantify, but have
potential for embarrassment should the misgivings bear fruit militates for
staying with the old. It also didn't help there were no strong supporters
willing to stand behind the code, which didn't help with the misgivings.
Had it not exited the tree then, the push to MP would have counted it as a
casualty absent a strong maintainer to make it MP safe.
...
I too am saddened to see such a retrograde step, but perhaps
I'm biased. When I arrived in 1127, the kernel had /proc but
still had ptrace as well. Why? Because no one was brave enough
to wade into sdb and adb.
...
I can sympathize with FreeBSD excuse someone cited elsewhere,
that nobody used the code so it should go--I'm always in favour
of improving programs by chopping sutff out--but I think the
decision here was backwards. The proper answer would have been
to teach ps et al to use /proc, not to invent a new complex of
system calls.
+1 that was my point. If the application code had been available @ UCB
earlier before the proliferation,
I think and /proc has been part of 4.2 or at least 4.3 not 4.4, I think
there would have been a better chance
of it being used.
I also agree about garbage collection, but this is a case where the right
solution would have been to try to get people to use the new interface.
The problem was ptrace was 'good enough' and there was no incentive so no
one did it.
Mark Litton's thesis was DBX which was being
written when 4.2 was being
developed. If Mark had had /proc the simplicity would have been
compelling. But once the code was written, it was hard to justify
switching.
It's my same observation about why Fortran still is #1 in the high end of
the business. It's just not interesting to replace it.
So what I'm asking us to try to do, is not just look at the technology in
a vacuum. Why was it not interesting to /proc for BSD. Clearly, Linux
added it (differently than Eighth Edition of course and the 4.4
implementation was much more like V8 that Linux would settle). People did
do the work to use it.
So why did *BSD not bring those versions of the utilities back?
My >>guess<< while they had added some things (like /proc) it was
different again and we got into the BSD != Linux stuff - which has been the
UNIX war all over again.
There might have been a bit of that too, but it was background noise. The
misgivings about the code, and the lack of a strong maintainer to cope with
the misgivings drive the decision. No one was there to bar the door when
the grim reaper came.
Sigh....
I dislike how Linux has tossed information about processes and
other system-related data into the same namespace (and now that
there is /sys as well as /proc, I wonder whether it's time to
divorce them, or even to move /proc into /sys/proc), but the
general direction of moving things into the file system makes
sense.
I agree, but let's just create a /sys/proc namespace and try to be
consistent. Here is a case where I wish *BSD would just pick up the Linux
solution and be done with it. It's not worth arguing.,
I have some qualms about adding more and more code to
I'm not so sure about that. I hate /dev/kmem solutions to problems, or any
solution that has to have many round-trips between the kernel and userland,
especially on MP systems where locking and consistency issues clash with
the desire for maximum performance...
Warner
the kernel that just does string processing
(making the kernel
bigger and more complicated, and widening the attack surface
for bad guys),
+1
though; maybe most of that stuff belongs not in
the OS proper but in a user-mode program that reads /dev/mem
and presents as a file system.
Agree although, I would love to see consistency and moving towards one
namespace & associated API that we all used.
4:51 p.m.
New subject: UNIX of choice these days?
On Mon, Sep 25, 2017 at 9:13 AM, Warner Losh <imp(a)bsdimp.com> wrote:
On Mon, Sep 25, 2017 at 8:16 AM, Clem Cole <clemc(a)ccc.com> wrote:
On Mon, Sep 25, 2017 at 8:07 AM, Norman Wilson <norman(a)oclsc.org> wrote:
In the case of procfs and FreeBSD, the issues were more complicated and
nuanced. The original /proc code came from 4.4BSD, and interacted with a
number of kernel subsystems. These subsystems were undergoing evolution at
the time (including a rather concerted rewrite of the VM to unify the
buffer cache). This churn there lead to inevitable changes being needed to
procfs to keep up with the new interfaces and such. Over time, there grew
the feeling that there some something quite wrong with procfs (rightly or
wrongly). There was a belief there were a number of unanticipated security
issues that were lingering in the code, but due to the changes not only in
API to the other sub-systems, but also in semantics. Kernel hackers that
studied the problem came away with an uneasy feeling, but nothing
actionable. This was the back-drop that slowed its adoption into new
utilities in the FreeBSD tree and kept people from wanting to push it
further until these misgivings could be explored and addressed. In the end,
it was easier to have a better understood code base (ptrace) that had an
icky interface over one that was cleaner, but that had clouds over it. As
fewer and fewer things used /proc, it became easier and easier to ignore,
and at some point people started worrying that this code that was basically
unused could be an attack vector on the systems, so it was retired.
...
I too am saddened to see such a retrograde step, but perhaps
I'm biased. When I arrived in 1127, the kernel had /proc but
still had ptrace as well. Why? Because no one was brave enough
to wade into sdb and adb.
...
I can sympathize with FreeBSD excuse someone cited elsewhere,
that nobody used the code so it should go--I'm always in favour
of improving programs by chopping sutff out--but I think the
decision here was backwards. The proper answer would have been
to teach ps et al to use /proc, not to invent a new complex of
system calls.
+1 that was my point. If the application code had been available @
UCB earlier before the proliferation,
I think and /proc has been part of 4.2 or at least 4.3 not 4.4, I think
there would have been a better chance
of it being used.
I also agree about garbage collection, but this is a case where the right
solution would have been to try to get people to use the new interface.
The problem was ptrace was 'good enough' and there was no incentive so no
one did it.
It's been a number of years since all this went
down, so my memory of it
may be clouded. Plus, I was FreeBSD's security officer for a time, and I'm
purposely not going back to my notes from the time since I promised to keep
all that business confidential (and I'm not exactly sure where they are).
So, there may be the odd detail wrong, or imprecision of language, but the
main thrust is there: new with issues that are hard to quantify, but have
potential for embarrassment should the misgivings bear fruit militates for
staying with the old. It also didn't help there were no strong supporters
willing to stand behind the code, which didn't help with the misgivings.
Had it not exited the tree then, the push to MP would have counted it as a
casualty absent a strong maintainer to make it MP safe.
OK. I've done some software archeology and the above isn't quite right.
Sorry for the misinformation.
FreeBSD still has /proc. It's still actively maintained.
We removed /proc from the default kernel and installation years ago due to
security concerns (and not just misgivings, there were several SAs in that
area). I was remembering the 'opt-in' discussions... Should have consulted
the notes...
The ctl interface in the referenced commit message is part of the debugging
interface. It wasn't as feature rich as gdb, and nothing used it so it was
removed. There's other parts of the debugging interface that still persist,
but those are in the process of being de-orbited. There are several
debuggers that use the ptrace interface, and making them all use /proc was
seen as rowing against the tide and not completely useful since /proc
wasn't enabled by default due to security concerns.
The rest of /proc is still around, but you have to really want it.
Kinda highlights, though, problems with the kitchen-sink approach. There's
bits of /proc that are quite useful, but since it was so expansive, it
represented a big security threat and so is off by default.
Warner
26 Sep
26 Sep
12:56 a.m.
New subject: UNIX of choice these days?
On Mon, Sep 25, 2017 at 9:52 AM Warner Losh <imp(a)bsdimp.com> wrote:
Kinda highlights, though, problems with the kitchen-sink approach. There's
bits of /proc that are quite useful, but since it was so expansive, it
represented a big security threat and so is off by default.
were you to limit proc to being just for processes are there issues still?
25 Sep
25 Sep
3:18 p.m.
New subject: UNIX of choice these days?
On Mon, Sep 25, 2017 at 10:16:11AM -0400, Clem Cole wrote:
So what I'm asking us to try to do, is not just
look at the technology in a
vacuum. Why was it not interesting to /proc for BSD. Clearly, Linux
added it (differently than Eighth Edition of course and the 4.4
implementation was much more like V8 that Linux would settle). People did
do the work to use it.
Linux's /proc was hugely different than the AT&T /proc, in a good way in
my opinion. It's sort of Tcl like :-), everything is a string. So you
can look at the files with cat. I think plan 9 went this way as well.
And the Linux /proc did and does so much more than AT&T /proc. You
can tune the system, debug the system, here's an example. You know
something is holding something open, you want to know what.
$ ps
PID TTY TIME CMD
2668 pts/8 00:00:00 bash
14153 pts/8 00:00:00 ps
$ cd /proc/2668/fd
$ ls -l
total 0
lrwx------ 1 lm lm 64 Sep 23 21:16 0 -> /dev/pts/8
lrwx------ 1 lm lm 64 Sep 23 21:16 1 -> /dev/pts/8
lrwx------ 1 lm lm 64 Sep 23 21:16 2 -> /dev/pts/8
lrwx------ 1 lm lm 64 Sep 23 21:39 255 -> /dev/pts/8
Now isn't that pleasant? (Yes, I know about lsof).
One could make an argument that for debugging you need a lighter weight
way to get the info, and maybe ptrace is lighter, I dunno. But for most
stuff the Linux /proc (it's really /system because it's about way way
more than processes) is super pleasant.
So why did *BSD not bring those versions of the
utilities back?
My >>guess<< while they had added some things (like /proc) it was different
again and we got into the BSD != Linux stuff - which has been the UNIX war
all over again.
Yeah, I don't see the two being compat. They could overlap but when you get
into specific tuning variables they won't match.
I suspect that no /proc in BSD is simple, there wasn't anyone who wanted to
put in the time to evolve it and maintain it.
3:30 p.m.
New subject: UNIX of choice these days?
On Mon, Sep 25, 2017 at 9:18 AM, Larry McVoy <lm(a)mcvoy.com> wrote:
There was very little overlap. And much of what was exported in linux as
/proc/blah was available as a syctl which mean the pressure to expand /proc
was lessened. There's pros and cons to sysctl (which is basically a second
name space for data from/about the kernel), but it was the path taken.
Filesystems can go too far (cf the fiasco of the efivar filesystem where
you could brick your box with an rm -rf, oops), and they can also be taken
not far enough. There's good reasons to avoid filesystems that are
intrusive into every part of the system (sysctl has a more restricted
context to execute in which can be more helpful than trying to cope with
vnodes and such in every driver). There's also bad reasons to avoid
filesystems as well (say because your VFS abstraction layer is complicated
and difficult to use)...
I suspect that no /proc in BSD is simple, there wasn't anyone who wanted to
On Mon, Sep 25, 2017 at 10:16:11AM -0400, Clem Cole
wrote:
I both love and hate this setup...
So what I'm asking us to try to do, is not
just look at the technology
in a
vacuum. Why was it not interesting to /proc for
BSD. Clearly, Linux
added it (differently than Eighth Edition of course and the 4.4
implementation was much more like V8 that Linux would settle). People
did
do the work to use it.
Linux's /proc was hugely different than the AT&T /proc, in a good way in
my opinion. It's sort of Tcl like :-), everything is a string. So you
can look at the files with cat. I think plan 9 went this way as well.
And the Linux /proc did and does so much more than
AT&T /proc.
Which is the other issue with the inherited 4.4 /proc
[...]
So why did
*BSD not bring those versions of the utilities back?
My >>guess<< while they had added some things (like /proc) it was
different
again and we got into the BSD != Linux stuff -
which has been the UNIX
war
all over again.
Yeah, I don't see the two being compat. They could overlap but when you
get
into specific tuning variables they won't match.
put in the time to evolve it and maintain it.
That's it in a one line summary. I posted a few more details as well, but
that's basically it. When the time came, nobody cared enough to even
object... Certainly nobody cared enough to understand the complex
interactions with other subsystems as they evolved to keep it up to snuff,
let alone innovate with new things to keep it interesting.
Warner
26 Sep
26 Sep
2:06 a.m.
New subject: UNIX of choice these days?
On 9/25/17 7:49 PM, Dave Horsfall wrote:
On Mon, 25 Sep 2017, Larry McVoy wrote:
It appears to be a file descriptor open to his controlling terminal.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/
lrwx------ 1 lm lm 64 Sep 23 21:39 255 ->
/dev/pts/8
What the heck is file descriptor 255?
2:53 p.m.
New subject: UNIX of choice these days?
On Mon, Sep 25, 2017 at 10:06:55PM -0400, Chet Ramey wrote:
On 9/25/17 7:49 PM, Dave Horsfall wrote:
LOL. I think he's wondering why the fd has the value of 255 and I dunno.
Some weird bash thing?
On Mon, 25 Sep 2017, Larry McVoy wrote:
It appears to be a file descriptor open to his controlling terminal. ????????lrwx------ 1 lm lm 64 Sep 23 21:39 255
-> /dev/pts/8
What the heck is file descriptor 255?
3:17 p.m.
New subject: UNIX of choice these days?
On 9/26/17 10:53 AM, Larry McVoy wrote:
On Mon, Sep 25, 2017 at 10:06:55PM -0400, Chet Ramey
wrote:
It's not weird. Bash keeps a file descriptor open to the controlling
terminal to use for job control and other terminal operations. After it
opens the ctty, it dups the file descriptor to something out of the usual
range people use to save and restore fds. It uses the RLIMIT_NOFILE
resource limit to determine the upper bound, but doesn't go past 256 (some
systems set that limit pretty high). So you have a file descriptor that the
shell can use but is close-on-exec and unusual enough to avoid being
stepped on.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/
On 9/25/17 7:49 PM, Dave Horsfall wrote:
LOL. I think he's wondering why the fd has the value of 255 and I dunno.
Some weird bash thing? On Mon, 25 Sep 2017, Larry McVoy wrote:
It appears to be a file descriptor open to his controlling terminal. ????????lrwx------ 1 lm lm 64 Sep 23 21:39 255
-> /dev/pts/8
What the heck is file descriptor 255? 
9:23 p.m.
New subject: UNIX of choice these days?
On Tue, 26 Sep 2017, Larry McVoy wrote:
LOL. I think he's wondering why the fd has the value of 255 and I
dunno. Some weird bash thing?
Exactly; why 255 of all things?
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
What the heck is file descriptor 255?
It appears to be a file descriptor open to his controlling terminal. 
9:43 p.m.
New subject: UNIX of choice these days?
Who's going to type:
<cmd> 2>&255
?
On 9/26/2017 5:23 PM, Dave Horsfall wrote:
On Tue, 26 Sep 2017, Larry McVoy wrote:
LOL. I think he's wondering why the fd has the value of 255 and I
dunno. Some weird bash thing?
Exactly; why 255 of all things?
What the heck is file descriptor 255?
It appears to be a file descriptor open to his controlling terminal. 
27 Sep
27 Sep
12:58 a.m.
New subject: UNIX of choice these days?
On Tue, 26 Sep 2017, Grant Taylor wrote:
Yeah, but still doesn't answer the question, application-wise. I'm gonna
guess (without digging through the source) that it's a "dup2(0, 255)*" or
something, to "save" a copy of stdin/out/err for some obscure reason.
[*]
OK, "getdtablesize() - 1" instead of 255...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
Exactly; why
255 of all things?
High order of 8 bits? (Assuming low order starts at 0.)
1:37 a.m.
New subject: UNIX of choice these days?
On 9/26/17 8:58 PM, Dave Horsfall wrote:
On Tue, 26 Sep 2017, Grant Taylor wrote:
Yeah, but still doesn't answer the question, application-wise. I'm gonna
guess (without digging through the source) that it's a "dup2(0, 255)*" or
something, to "save" a copy of stdin/out/err for some obscure reason.
I already answered this.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/
Exactly;
why 255 of all things?
High order of 8 bits? (Assuming low order starts at 0.)
2:02 a.m.
New subject: UNIX of choice these days?
On Tue, Sep 26, 2017 at 09:37:13PM -0400, Chet Ramey wrote:
On 9/26/17 8:58 PM, Dave Horsfall wrote:
OK, I'm gonna be that guy because I've learned when I ask, I learn.
You answered but I didn't get any insight. Why have an extra fd talking
to the tty? bash has 0, 1, 2 talking to it. If it were redirected
would it have 255 pointing to some random tty? I don't get the reason
for the extra fd.
On Tue, 26 Sep 2017, Grant Taylor wrote:
Yeah, but still doesn't answer the question, application-wise.?? I'm gonna
guess (without digging through the source) that it's a "dup2(0, 255)*" or
something, to "save" a copy of stdin/out/err for some obscure reason.
I already answered this. Exactly;
why 255 of all things?
High order of 8 bits??? (Assuming low order starts at 0.)
1:50 p.m.
New subject: UNIX of choice these days?
On 9/26/17 10:02 PM, Larry McVoy wrote:
OK, I'm gonna be that guy because I've learned when I ask, I learn.
You answered but I didn't get any insight. Why have an extra fd talking
to the tty? bash has 0, 1, 2 talking to it. If it were redirected
would it have 255 pointing to some random tty? I don't get the reason
for the extra fd.
OK. The only way to guarantee you have a descriptor open to your
controlling terminal is to open /dev/tty yourself. You can run `bash -im'
and have yourself an interactive shell with job control enabled no matter
where stdin/stdout/stderr point, and they can be redirected at any point
during execution, so you can't count on them. But why do you have to have
the fd in the first place?
My initial message said you need it for "job control and other terminal
operations." Here's what that means.
You initially need a handle to your controlling terminal to determine
whether or not you have one and whether you're in the background. If you
don't have a controlling terminal, job control is impossible. You need the
terminal's process group to determine whether or not you're in the
foreground, and to get that you need a handle to the controlling tty. Every
shell does this.
Once you've determined the original tty pgrp, you need to become a process
group leader if you're not one already and set the terminal's process group
to your own so you can stay in the foreground. If you don't, you can't read
from the terminal. If you can't change the terminal's process group, you
can't enable job control. You need the handle to call tcsetpgrp(). Again,
this is something every shell does.
Now that you've set up job control, and you have a handle to your
controlling terminal, you might as well keep it around -- your controlling
terminal is not going to change throughout the life of the process.
You'll need that handle every time you want to set the terminal's process
group, and that's the essence of job control: setting the terminal's
process group to the process group ID of whatever you've determined is the
foreground job (which, most of the time, is yourself). So bash saves it
to an fd that is unlikely to collide with anything else, which is essential
because bash allows the file descriptor numbers used in redirections to
consist of multiple digits. (I explained the algorithm bash uses; other
shells do something different. dash and zsh use fd 10. mksh uses 24 (?).
ksh93 uses fd 2 no matter what, so you don't get job control if you
redirect stderr away from the terminal.)
There is another "terminal operation" for which the controlling terminal
is required: saving and restoring terminal state. Bash fetches the terminal
attributes before running an external command, and restores the attributes
if a process exits with a non-zero status or is stopped. The former is a
useful convenience; the latter is required. You need the handle for the
calls to tcgetattr()/tcsetattr().
You can get away without all of this stuff, of course. But that makes job
control harder and less efficient.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/
Yeah, but still doesn't answer the question,
application-wise.?? I'm gonna
guess (without digging through the source) that it's a "dup2(0, 255)*" or
something, to "save" a copy of stdin/out/err for some obscure reason.
I already answered this.
2:17 p.m.
New subject: UNIX of choice these days?
On Wed, Sep 27, 2017 at 09:50:10AM -0400, Chet Ramey wrote:
On 9/26/17 10:02 PM, Larry McVoy wrote:
OK, I'm gonna be that guy because I've learned when I ask, I learn.
You answered but I didn't get any insight. Why have an extra fd talking
to the tty? bash has 0, 1, 2 talking to it. If it were redirected
would it have 255 pointing to some random tty? I don't get the reason
for the extra fd.
OK. The only way to guarantee you have a descriptor open to your
controlling terminal is to open /dev/tty yourself. You can run `bash -im'
and have yourself an interactive shell with job control enabled no matter
where stdin/stdout/stderr point, and they can be redirected at any point
during execution, so you can't count on them. But why do you have to have
the fd in the first place?
All the tty stuff wasn't my question, I get all that, I did POSIX conformance
in SunOS, there was a time when I dreamed about setsid() et al :)
Yeah, but still doesn't answer the question,
application-wise.?? I'm gonna
guess (without digging through the source) that it's a "dup2(0, 255)*" or
something, to "save" a copy of stdin/out/err for some obscure reason.
I already answered this. ksh93 uses fd 2 no matter what, so you don't get
job control if you
redirect stderr away from the terminal.)
So that's the behaviour I'm used to (dating myself but this is TUHS so...)
My question really was why use an extra fd? If I run
bash something > /dev/null 2>&1
duh. ksh93 wouldn't let you ^Z that, eh? OK, makes sense, I hadn't
thought it through. Sorry for the brain fart.
28 Sep
28 Sep
8:10 a.m.
New subject: UNIX of choice these days?
On Wed, Sep 27, 2017 at 07:17:06AM -0700, Larry McVoy wrote:
On Wed, Sep 27, 2017 at 09:50:10AM -0400, Chet Ramey
wrote:
> ksh93 uses fd 2 no matter what, so you don't get job control if you
> redirect stderr away from the terminal.)
I'm fairly sure bash used to do something similar.
I recall having to hack it around '07/'08 to cope with being started
(possibly passing '-i' - I can't recall), when stderr was a pipe,
stdin/stout were a pty (which was the controlling terminal), yet finding
that job control didn't work.
DF
12:34 p.m.
New subject: UNIX of choice these days?
On 9/28/17 4:10 AM, Derek Fawcus wrote:
On Wed, Sep 27, 2017 at 07:17:06AM -0700, Larry McVoy
wrote:
Yes, that changed in 2007 based on bug reports you filed while working
at Cisco. The first release where it appeared was bash-4.0.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/
On Wed, Sep 27, 2017 at 09:50:10AM -0400, Chet
Ramey wrote:
> ksh93 uses fd 2 no matter what, so you don't get job control if you
> redirect stderr away from the terminal.)
I'm fairly sure bash used to do something similar.
I recall having to hack it around '07/'08 to cope with being started
(possibly passing '-i' - I can't recall), when stderr was a pipe,
stdin/stout were a pty (which was the controlling terminal), yet finding
that job control didn't work.
27 Sep
27 Sep
3:42 a.m.
New subject: UNIX of choice these days?
On Tue, 26 Sep 2017, Chet Ramey wrote:
You didn't, actually, but I'll be generous and assume that you genuinely
missed my point as opposed to being deliberately obtuse; I don't think I
can make it any clearer, but I see that Larry "got it".
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
Yeah, but
still doesn't answer the question, application-wise. I'm
gonna guess (without digging through the source) that it's a "dup2(0,
255)*" or something, to "save" a copy of stdin/out/err for some obscure
reason.
I already answered this.
2:35 p.m.
New subject: UNIX of choice these days?
On 9/26/17 11:42 PM, Dave Horsfall wrote:
On Tue, 26 Sep 2017, Chet Ramey wrote:
You didn't, actually,
I really did: job control and terminal operations. I added more detail
in another message this morning.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/
Yeah, but
still doesn't answer the question, application-wise. I'm
gonna guess (without digging through the source) that it's a "dup2(0,
255)*" or something, to "save" a copy of stdin/out/err for some obscure
reason.
I already answered this.
2402
days inactive
2405
days old
22 comments
10 participants
participants (10)
-
Arthur Krewat -
Chet Ramey -
Clem Cole -
Dave Horsfall -
Derek Fawcus -
Grant Taylor -
Larry McVoy -
Norman Wilson -
ron minnich -
Warner Losh