-bash: cannot set terminal process group

[Walter Dnes]

I'm running 3.4.0-r2. I've installed, and am working on adding packages. it works OK with sh, but I much prefer bash (no flamewars intended). Anyhow, I get some warnings when logging in with bash. The following is a screen-capture of an ssh session from "i3" (linux physical machine) to "d531" (minix physical machine). My Google searches have not helped. I did see that users with similar problems (in other OS's) were asked to "ls /dev/pt*" and "cat /etc/fstab". These warnings happen only in bash; both as regular user, and when root does "/usr/pkg/bin/bash". I don't dare change root's shell yet. I can log in, but I don't know if the bash messages signify a severe problem.

[i3][waltdnes][~] ssh d531
For post-installation usage tips such as installing binary
packages, please see:
http://wiki.minix3.org/UsersGuide/PostInstallation

For more information on how to use MINIX 3, see the wiki:
http://wiki.minix3.org

We'd like your feedback: http://minix3.org/community/

-bash: cannot set terminal process group (-1): Inappropriate ioctl for device
-bash: no job control in this shell
[d531][waltdnes][~]ls /dev/pt*
/dev/ptmx  /dev/ptyp4 /dev/ptyp9 /dev/ptype /dev/ptyq3 /dev/ptyq8 /dev/ptyqd
/dev/ptyp0 /dev/ptyp5 /dev/ptypa /dev/ptypf /dev/ptyq4 /dev/ptyq9 /dev/ptyqe
/dev/ptyp1 /dev/ptyp6 /dev/ptypb /dev/ptyq0 /dev/ptyq5 /dev/ptyqa /dev/ptyqf
/dev/ptyp2 /dev/ptyp7 /dev/ptypc /dev/ptyq1 /dev/ptyq6 /dev/ptyqb
/dev/ptyp3 /dev/ptyp8 /dev/ptypd /dev/ptyq2 /dev/ptyq7 /dev/ptyqc

/dev/pts:
0
[d531][waltdnes][~]cat /etc/fstab
/dev/c0d0p0s0   /               mfs     rw                      0       1
/dev/c0d0p0s2   /usr            mfs     rw                      0       2
/dev/c0d0p0s1   /home   mfs     rw                      0       2
none            /sys            devman  rw,rslabel=devman       0       0
none            /dev/pts        ptyfs   rw,rslabel=ptyfs        0       0
[d531][waltdnes][~]

[Jean-Baptiste Boric]

-bash: cannot set terminal process group (-1): Inappropriate ioctl for device
-bash: no job control in this shell

I recall Minix 3 not supporting job control from a Tanenbaum's talk, so when bash tries to set up job control it complains that it doesn't work.

I think these messages are harmless, but I wouldn't want bash as the default root shell just in case.

[r0ller]

It does not really prove anything but just wanted to add that I'm using bash in minix3 for some years now and haven't encountered any issues.

[Martin Vahi]

As of 2016_03_11 I have never used MINIX, not even booted it once, but I tend to watch videos while eating and one of those videos happened to be the MINIX 3 introduction at

https://www.youtube.com/watch?v=oS4UWgHtRDw

The search phrase, how I found it, probably contained "secure software architecture" and when I noticed that the talk is about MINIX, then I remembered that "MINIX is the operating system that Linus Torvalds was forbidden to tinker with", but since I am always willing to learn from the best, even, if it is the old devil itself, I watched the video to the end and I was really surprised that the MINIX was licensed under BSD since year 2000. I actually finished high-scool in 2000, year 2000 was my fresh-man year at the University of Tartu and I probably started to use anything non-Windows on my main home computer in 2002 or 2003, may be 2001, so some really bad decisions can take about 16 years to fix in the "public relations" realm. If the Andrew Tanenbaum did not mention the licensing part at his year 2015 presentation, I would probably not be writing this comment here even today.

Well, one way or the other, the reason, why I logged on to the Google Groups right now and why I'm writing the current comment here is that I wanted to let You people now that from applications software developer perspective it is PARAMOUNT that the various shell scripts WORK and one of the reasons, why I dumped BSD was that the huge amount of effort that I spent on creating my Ruby and Bash scripts did not pay off on BSD due to the fact that the standard, "simple", utilities like "ps" work DIFFERENTLY on Linux and BSD.

That is to say, people, who write Ruby, Bash, probably also Python, do not care so much about the kernel API, but the incompatibilities of command-line utilities is a SHOW-STOPPER, so if You can just get the command line utilities to work the way they work on Linux, then You do not actually need any Linux compatibility to port applications to whatever nice operating system that You got Your research funding for.

Another line of thought is that given the "high level synthesis" trend, where FPGA configuration binary is compiled from C source, in stead of hardware or operating system specific libraries applications might just use some programming language as the middle-layer. The programming language must support threads through its specification and there must be a compiler that is able to translate that programming language to FPGA configuration or some Raspberry PI "backend" or some MUEN "port" "backend".

http://www.adacore.com/press/muen-separation-kernel/

As of 2016_03 it seems that from theoretical perspective the most novel programming language is

ParaSail
https://www.youtube.com/watch?v=5h7YfDi8t78
(a pet project of AdaCore researcher, Tucker Taft, who's thinking style might be assessed from
https://www.youtube.com/watch?v=5h7YfDi8t78
)

May be the FPGA related translation toolchain might include

http://www.clifford.at/icestorm/

To sum it up, the idea that applications software depends on operating system specific utilities, which in turn depend on operating system kernel (API), seems to be not the most optimal, because it is possible to use a design pattern, where in stead of a cream-cake-stack (layers of jam, cream, berries, baked white bread) it is possible to use a "pizza architecture", where the white-bread part, the foundation, is a programming language, applications are the things on the pizza and the various operating system utilities are just bunch of applications that may or might not be present, but that they are assured to have a consistent command-line API, so that if the utility, for example, "ps", "ls", "uname", are available on the PATH at all, then all bash scripts that use them, work the same way, NOT the way it currently is, where on BSD the "which ps" says that the "ps" is available on the PATH and when the Bash script tries to use the "ps", then it might behave one way on Linux and another way on BSD. From applications perspective it is easy to check, if some utility is available, on the PATH, but it is terribly hard, laborious from coding perspective, to check, whether the thing available on the PATH has a certain behavior, because that code has to implement a test suite to find that out.

The "pizza architecture" also covers the bare-metal cases, the style that is being used at developing micro-controller applications, where there is no operating system, just plain C code, except that in stead of C code the ParaSail or something similar would be used, may be with restrictions in the form of forbidding "malloc". There is already a totally open source (the hardware code is open) multi-CPU-microcontroller, Parallax Propeller, so the ParaSail for embedded systems is certainly not a stretch.

https://www.parallax.com/microcontrollers/propeller-1-open-source

Even the main-stream multi-core CPU vendors move to open source hardware:

http://www.adapteva.com/andreas-blog/why-i-will-be-using-the-risc-v-in-my-next-chip/

The RISC-V is supposed to offer competition to the ARM at low power applications:

http://riscv.org/

That follows the current ARM trend, where the same CPU-architecture is used at both, embedded applications and servers, just that servers can have far more CPU-cores installed.

Well, anyways, thank You for reading my comment and I know that my comment is hard to summarize, because it covers so many different topics, but if You look at it as a whole, then hopefully You can better grasp, where the MINIX fits in from applications software developer perspective and from the general, overall, picture. My cook-book-style recommendations is that make sure that command line utilities behave like they behave at Linux, but the command line utilities do not have to be tied to any particular operating system architecture and the way to save development effort at such a huge task might be to get the foundation part, the programming language part, right and then move to the operating system development and the development of various utilities. Meanwhile I'll be "slacking around" by not contributing anything to anyone, be happy at using Linux and trying to make sense of ParaSail or at least, part of my learning agenda, because I also have to earn a living and try to get things done at some other fronts.

Thank You again for reading this and I hope that I was able to write at least somewhat useful comment. :-)

[Martin Vahi]

On other thing: after pushing the "send" button of my previous post I was informed that my submission is going to be moderated before publishing.

You already did a nasty mistake with the MINIX license at the early years of MINIX, so PLEASE, do not make another dumb mistake and get rid of the stupid moderation of this news group. Other open source projects can do without moderation and it is not that bad at all, there is not much spam, if any, at their Google News groups. I do not think that MINIX will have any more trouble than the other news groups.

Happy moderating of this message. :-D

[David van Moolenbroek]

Hello,

Please do not hijack discussion threads; it is considered rude. The contents of your post do suggest that you set out to be rude though.

> one of the reasons, why I dumped BSD was that the huge amount of effort that I spent on creating my Ruby and Bash scripts did not pay off on BSD due to the fact that the standard, "simple", utilities like "ps" work DIFFERENTLY on Linux and BSD.

I'm afraid this says more about you as an application software developer than about those operating systems. Utilities such as ps(1) have a subset of options that are standardized as part of the Open Group's POSIX specification. For example, take a look here:

  http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ps.html

If you stick to that standardized subset, you will have very few problems porting your scripts between platforms. If you do not, you are in for a world of pain, especially because the GNU utilities (which, as you may know, make up most of Linux's basic userland) tend to have a lot of nonportable extensions. As such, using Linux as initial platform for development of portable scripts is arguably a rather poor choice, especially if you are not aware of standards such as the POSIX specification.

> if You can just get the command line utilities to work the way they work on Linux, then You do not actually need any Linux compatibility to port applications to whatever nice operating system that You got Your research funding for.

No thanks. As Tanenbaum already mentioned in the talk that you linked, MINIX3 is currently switching over to the NetBSD userland, and for good reason. We have no intention of making the userland of MINIX3 behave more like the GNU utilities. If you as an application developer do your job right, that will not be necessary either.

> Meanwhile I'll be "slacking around" by not contributing anything to anyone

That's quite okay.

> You already did a nasty mistake with the MINIX license at the early years of MINIX

Perhaps you should read a bit more about the history of MINIX first..

> so PLEASE, do not make another dumb mistake and get rid of the stupid moderation of this news group.

We're good, but thanks for your input.

Regards,
David

[Martin Vahi]

Thank You for Your answer. :-)

reede, 11. märts 2016 16:26.10 UTC kirjutas David van Moolenbroek:

...

Please do not hijack discussion threads; it is considered rude. The contents of your post do suggest that you set out to be rude though.

...

Well, I guess different psychoanalysts can disagree on their assessment, what I was set out to do here, but what regards to the hijacking of discussions, then regardless of whether You define it to be rude or not I claim that CREATIVITY DEMANDS SOME DISCOURSE and FREE FLIGHT OF THOUGHT. If people at a discussion are all muzzled due to the requirement that everyone must strictly stick to the firm limits set by the opening posting, then it is not possible to improve on each others thoughts without creating a whole huge set of threads. One thing is staying focused to get things done, but another thing is giving each-other vaguely related hints, a bit like search engines offer, the way You very helpfully gave me by

 
> ...

Utilities such as ps(1) have a subset of options that are standardized as part of the Open Group's POSIX specification. For example, take a look here:

  http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ps.html

If you stick to that standardized subset, you will have very few problems porting your scripts between platforms. If you do not, you are in for a world of pain, especially because the GNU utilities (which, as you may know, make up most of Linux's basic userland) tend to have a lot of nonportable extensions. As such, using Linux as initial platform for development of portable scripts is arguably a rather poor choice, especially if you are not aware of standards such as the POSIX specification.

...

and I Thank You for that helpful hint without minding You "hijacking a discussion". :-D

Well, I guess that we all have our strengths and weaknesses and I suspect that I start to have an idea, why the MINIX community building part has some hardships. My recommendation is that You should try to accept the fact that the activity of other people is OUTSIDE of the CONTROL OF PROJECT FOUNDERS and the tool for protecting oneself from the mess that is created by others is _forking_. Just let people roam around at their own, private, forks of the MINIX and then if they produce some really neat ideas with crappy implementation, then re-implement the idea properly from scratch or, if their code has the style that You like, cherry-pick what You like and tell the other offers politely that the offer does not meet Your style preferences.

Be and let be, design and let design. :-)

Thank You for reading my comment.

[Antoine LECA]

On 2016-03-11 14:46Z, Martin Vahi wrote:
>
> "MINIX is the operating system that Linus Torvalds was
> forbidden to tinker with",

Methinks that 'prohibition' was set up by Linus himself; or more exactly
that the affair was later described as a prohibition.
Anyway it was a long time ago.


> people [k]now that from applications software developer

> perspective it is PARAMOUNT that the various shell scripts WORK

I disagree. I firmly believe any professional application should not
rely on scripts. If it has to, then it should be the job of the
application developer to make sure the script is portable enough (and at
the very least, to be sure it runs flawlessly on common systems.)

Baring that work, the application should be categorized as "requiring
xxxx as operating system," where xxx is the (only) OS of the developer.
Which is, by the way, a perfectly acceptable requirement, and a very
common one for professional applications.

> That is to say, people, who write Ruby, Bash, probably also Python, do not
> care so much about the kernel API, but the incompatibilities of
> command-line utilities is a SHOW-STOPPER, so if You can just get the
> command line utilities to work the way they work on Linux

Your definition of "compatibility" seems to be "be the same as it is on
[GNU/]Linux." Then an obvious solution is to stay using GNU/Linux: as
far as I know, it is the most common operating system for servers, by a
wide margin, once you discard Windows.
So I do not see where is the problem.

> then You do not
> actually need any Linux compatibility to port applications to whatever nice
> operating system that You got Your research funding for.

Actually it did not work. For a long time, MINIX had supported the GNU
utilities as an alternate command-line environment (and it is the same
for the *BSD systems.) But the Linux-targeted applications do not work.
As a result, many people designed Linux compatibility layers, to ensure
those applications worked. Later these layers showed to be difficult to
support; then the demand for such compatibility went down, as the market
coalesced (around Linux.)
By the way, before year 2000, you could replace "Linux" with "Xenix" and
"compatibility layer" with "iBCS": the result is the same picture.
Also you can try with DOS+MVS, DOS+VDM, Windows+WOW, Win32+WOW64 etc.

Anyway, MINIX designers went away from that trail years ago. It was a
conscious decision, based on years of experience of non-success.
It appears a bit difficult to show up and say that it should work now.

> To sum it up, the idea that applications software depends on operating
> system specific utilities, which in turn depend on operating system kernel

> (API), seems to be not the most optimal [...]

Thanks to confirm that scripts (which are those which using these
utilities) are not the paramount.

> My cook-book-style recommendations is that make
> sure that command line utilities behave like they behave at Linux, but the
> command line utilities do not have to be tied to any particular operating
> system architecture

That is the point of the GNU operating system (you seem to use Linux as
a moniker for it, but it is really the GNU operating system, not Linux
which is really one "particular operating system architecture.")
Since many people are using the GNU/Linux operating system, they would
be compatible with your view; so there should not be any problem.
The MINIX designers happen to not share your view. Let it be.


Antoine