echo output from a script

I have a sysinit script that starts another script.
The problem is that this script cannot print anything on the screen
using ‘echo’ but when I add ‘echo’ into sysinit it prints fine.
The other thing is if I start ifconfig from the script it prints
some info on the screen but not the output of the ‘echo’ command.

There is no Dev.ansi started since I don’t need any console i/o and
the OS is QNX4.25

So, can anyone tell me why and how the shell that executes sysinit can print
'echo’s but any other shell that started from within sysinit cannot?

Thanks,
Igor

Igor <spama@nihrena.net> wrote:

I have a sysinit script that starts another script.
The problem is that this script cannot print anything on the screen
using ‘echo’ but when I add ‘echo’ into sysinit it prints fine.
The other thing is if I start ifconfig from the script it prints
some info on the screen but not the output of the ‘echo’ command.

There is no Dev.ansi started since I don’t need any console i/o and
the OS is QNX4.25

So, can anyone tell me why and how the shell that executes sysinit can print
'echo’s but any other shell that started from within sysinit cannot?

Not sure why – had a guess, but the fact that ifconfig can get its output
displayed, but a second shell cannot, makes that seem less likely.

Do you actually need the other shell scripts run by new instances of the
shell? That is, do they actually need to be run in parallel or in the
background, or could you try working around this by using the ‘.’
command to include them into the current shell (that is have the same
process execute those sub-scripts, rather than spawning a new shell
process)?

When you don’t have a console, sysinit is setup so that it’s fds (0,1,2)
point to Proc, and Proc dumps the output to its debug device (which defaults
to raw video output). There may be some work that is done in the creation
of a new shell whereby the child shell doesn’t inherit the fds, or tries to
do some operation on them that Proc doesn’t support (since it isn’t a
real terminal device) and because of this, the shell loses access to
stdout.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

I seem to figure out why sysinit.1 can output but any other script
that was started by the sysinit.1 cannot.
The thing is that sysinit.1 starts from ‘set -i’ which I guess does the
trick.
This -i option seems to not documented at least it’s not listed in the list
of other options of the set command.

I wonder why?

Do you actually need the other shell scripts run by new instances of the
shell? That is, do they actually need to be run in parallel or in the
background, or could you try working around this by using the ‘.’
command to include them into the current shell (that is have the same
process execute those sub-scripts, rather than spawning a new shell
process)?

When you don’t have a console, sysinit is setup so that it’s fds (0,1,2)
point to Proc, and Proc dumps the output to its debug device (which
defaults
to raw video output). There may be some work that is done in the creation
of a new shell whereby the child shell doesn’t inherit the fds, or tries
to
do some operation on them that Proc doesn’t support (since it isn’t a
real terminal device) and because of this, the shell loses access to
stdout.

I guess you are right. Th mistery was how /bin/sh was able to find out when
it needs
to perform some operation on stdout and when it does not.

Thanks for the help,
Igor

Igor <spama@nihrena.net> wrote:

I seem to figure out why sysinit.1 can output but any other script
that was started by the sysinit.1 cannot.
The thing is that sysinit.1 starts from ‘set -i’ which I guess does the
trick.
This -i option seems to not documented at least it’s not listed in the list
of other options of the set command.

I wonder why?

Oversight, probably.

That “-i” option really is the same as running your shell with the -i
option, and that is documented and would have the same effect.

e.g. /bin/sh -i

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.