#Shell/CLI Questions
5 messages in this thread
Larry, I found the problem with the TCB program. I was using a
TST.W (A0) vice the correct TST.B (A0) command to test for a null CLI
input ( the 'TCB<cr>' case ). I fixed that and tested it — it runs
OK now.
I don't know what to do about the Shell though — The TCB program gets
its inputs ( I hope ) just like any other CLI command — Register A0
points to the CLI input string address and D0 contains the strings length
in bytes. Apparently when working from a 'Shell' A0 and D0 no longer
contain this information and the TCB program gets badly confused.
Where do I get the input command string address when running from a
Shell? If I know this address then it should be easy to make TCB work
correctly either from the CLI or Shell. I've never used the 'shell'
( which 'shell'?) and I don't know much about its operation. I'd like
the TCB program to work correctly from the CLI or the Shell, but I need
help in figuring out how to do this.
Al Aburto
If you mean Matt Dillon's shell, csh, A0 and D0 relate to command line in the
usual way, except that csh seems to insert a space character just before the
newline that is just before the terminating null. I think it does this
consistently, but I'm not wholly sure. This may also have been changed in the
latest csh revision (2.06M, which is in DL9 on this forum), though I didn't see
any mention of it in the release notes.
Nick
Thanks Nick ….. The trailing space character may be a problem, but
as long as A0 and D0 are correct then I can write a little routine to
delete trailing spaces in the command line input string …. this should
take care of any problems when running from csh…
The trouble is that my program asks for a Task Name input and when I use
_LVOFindTask() there must be an exact match between the CLI input Task
Name and the Task Name stored in memory.
Thanks again.
Till Later ….. Al Aburto
Al, the only pronblem I attributed to the shell (running metacomco's shell),
was the TCB <CR> command (note the space). I think the shell stripped off the
space. Since you have fixed that, it should be no problem.
When I ram TCB <CR> from a new CLI, it worked fine, up until the end of the
listing, where it went into the alternat charset and finally GURUed. I think
there may have been some other cause than the shell though. I'll give the
latest version a workout with and without the shell and let you know what
happens.
Regards, Larry.
Larry, I'm re-writing the TCB program to handle Upper or Lower case
(except for the TaskName input) and to delete trailing spaces in the
CLI input string …. I'll upload the revised program (TCB.ARC) ….
I don't know what to think of the Alternate characters that appeared
at the end of the 'TCB <cr>' listing ….. I know one thing though
— the amiga.lib _printf routine will cause a nasty GURU if the string
length its trying to print is greater than approximately 180 characters
or so. I found this out the hard way (after many GURU's).
Actually the last task I get from 'TCB<cr>' is flagged as 'Invalid' in
the Task Node Structure. The TaskName pointer is probably also Invalid
( 'GIGO' for the _printf routine ) — I'll fix this too Larry . If the
Task is flagged as 'Invalid' I'll just print out a default TaskName
( '*** ( Invalid Task ) ***' ) and otherwise just ignore the TaskName
(possibly garbage) pointer in the Task Node Structure.
Thanks for the help!
Till Later … Al Aburto