I'm seeing "stty: standard input: Inappropriate ioctl for device" when scripts are run from cron, they run fine from the root account command line. Now that I'm testing the a-shell exit status code my scripts are not working as A-Shell is returning status=1.

Here's the command line of one script



here are the contenfts of usersec.do
[code
:S
LOG RUN:
:R
USERSEC/$0:$1
:S
HOST
[/code]

Any idea why this error is occurring? Thanks in advance.

Usually that error refers to an attempt to request some kind of I/O attribute (like noecho?) that doesn't make sense for a non terminal. Or, considering that it works for root, isn't allowed due to the privileges on the driver in question.

If the message shows up in the ashlog, then we can easily identify the culprit. Otherwise, I may need to do some experimentation to see if I can reproduce it. It may be a matter of adding another IF conditional to the A-Shell code to prevent certain terminal-dependent operations like that from being executed.

There's nothing in ashlog, unfortunately.

I think I've confirmed that it isn't ECHO/NOECHO (at least I can execute an ashell command that uses both, and performs input from the DO file, and returns 0).

So we may need to dig a bit deeper into what USERSEC is doing that might be related to terminal input status.

BTW, where do you see the error message? In the redirected output? Is it feasible to add some additional outputs to help localize the issue. It seems like it either has to be on startup (in which case it would affect every ashell process run from crontab), or it is specific to some program function. Maybe we should first confirm that you can run a simple Hello World operation without getting the error.

If it happens with even the simplest A-Shell program, then my suspicion turns to it being related to the startup scripts for the process (which might also explain why being root makes it go away, i.e. root has a different startup script.) The reference to "stty" suggests that you may actually have a stty command in your startup script. In that case, assuming you want to keep it, you may need to condition it on being interactive. One way to do that (with bash) would be to check for i in the current shell options, something like ...

It's affecting all of the cron jobs that I have looked at so far. Not specific to USERSEC. All of the cron jobs should use the same switches.

USERSEC accepts a mode character parameter, and user parameter. It uses fn'switches() to process the command line. Then retrieves some data from an INI file using INIX, and prints the desired out via "? user$". There shouldn't be any other output.

I can see it in the redirected output. Nothing other than IN/OUT info in the ashlog.

I'm attaching the start script, there's not any stty.

This also happens with a cronjob like this


I guess never noticed this before because we weren't testing an exitcode from A-Shell, and the jobs run fine even with the error message.

Just to reduce this to the lowest common denominator, if the DO file is reduced to just a LOG and a HOST command, the error still occurs? If so, it's either in the standard ashell startup/shutdown (in which case I'm not sure why I can't reproduce it), or it's in the login scripts prior to executing ashell. We can maybe separate that out by trying a crontab entry like:

where test.sh contains something like:

If that works without error, then I'm not sure how else to pin it down other than via some messages which end up in the redirected output. (Running ashell commands via crontab is quite common, and while it's likely that most of the time there is no explicit test for the return code, if this was universal I think someone would have seen it in the redirected output. I've grepped for variations of the error message in several dozen redirected output files but haven't seen any occurrences.) Which suggests something code- or site-specific. I'm just not sure what.

Changing the DO file to the following and the error still occurs.





I updated the script to not call A-Shell and the error does not occur.

Running your test script from cron I see the error in test.log




Running the test.sh manually to hopefully see an issue.

The first time I saw a rebuilding job table message.
The second time ran manually this the output


I changed the DO file to just HOST and test.log contains.

That certainly does sound like A-Shell is the culprit. And I think I've located the where it happens. Stay tuned for another patch...

This turned out to be more complicated than expected. It turns out that the actual cause of the "inappropriate ioctl" error is unavoidably connected with the very act of testing to see if the process has a real terminal. The standard function for that is isatty(), which I didn't realize uses ioctl() internally, and the fact of the returned error, to determine that we don't have a terminal. Here's one post that seems to confirm my experience...

should-i-try-to-get-rid-of-inappropriate-ioctl-for-device-in-strace-output-for

But, it was also the case that A-Shell was failing to reset the exit status after a system call had set it. Apparently some system calls will reset the status on success, and others won't, which is why I was getting a 0 exit status in my test and you were getting a 1. (When I further simplified mine, I was able to reproduce that.) So this latest patch does fix that problem ...

ash-6.5.1717.15-el7-upd.tz

I'm not quite sure what to suggest about the text of the error message showing up in your redirected output, other than perhaps to not merge the stderr and stdout.

This one fixes the exit code for me!

I'm not really concerned about the text of the error being in the redirect. I guess I could see forgetting why it's there down the line, and raising a flag again. It's not worth spending a lot of time on.