Will like to know how to write a program to have two shell prompt
signs to show up after the program is closed instead of just one.
Control Z will make BASH shell to produce one prompt sign. Any way to
send a control Z to the shell interpreter from within a program? |
Request for Question Clarification by
krobert-ga
on
11 Feb 2003 20:18 PST
ga100-ga,
Are you trying to get two shells to open on the same terminal screen?
Or, are you just trying to change the way that your prompt looks?
krobert-ga
|
Clarification of Question by
ga1000-ga
on
11 Feb 2003 20:31 PST
Two shells to open on the same screen. In my opinion, by sending a
control Z to the shell interpreter from within the program, if that is
possible.
|
Request for Question Clarification by
sycophant-ga
on
11 Feb 2003 20:39 PST
Ctrl-Z isn't really two shells, it simply backgrounds your current
task and allows additional commands to be issued. The backgrounded
process will continue in the background, as required, and send a
message to your terminal when it is finished, or simply wait until it
is brought to the foreground again.
The same thing happens when you append a '&' to a command.
For exmaple, this is what happens when I background a 'sleep':
[user@host ~]$ sleep 10 &
[1] 7989
[user@host ~]$ (Return after 10 seconds)
[1]+ Done sleep 10
[user@host ~]$
This doesn't seem to be quite what you are trying to do
Can you clarify precisely what you are trying to do? I am still quite
unclear.
Regards,
sycophant-ga
|
Clarification of Question by
ga1000-ga
on
11 Feb 2003 21:45 PST
Please look at an earlier question of mine.
I have a newly designed RS232 card, a newly designed Linux device
driver for that. ( I am not the designer)
When a program finishes running, the shell prompt would not come back.
Maybe the sofware flow control is not done right, I do not know. I am
trying to find out what is going on.
Since control Z can bring the prompt sign back, I thought may be I
could solve the problem, in a not so elegant way, by sending the
control Z from within the program, to get the prompt sign back.
The goal is actually to find out why the prompt is missing.
If somebody is interest or qualified to debug this problem, will be
more than happy to send the terminal to him to debug, with a
reasonable question/answer fee.
The problem happens in Linux only. So hardware has no problem.
|
Request for Question Clarification by
maniac-ga
on
12 Feb 2003 18:28 PST
Hello Ga1000,
My #1 suggestion from a week ago was to check the terminal settings
(or perhaps replace) for the Wyse 60. The Wyse terminals in particular
have modes where it will not scroll when the cursor reaches the bottom
of the display. As an alternative, a change to the VT100 personality
may "solve" this problem. The Wyse site also had a message indicating
a problem with "older" terminals where a full reset was necessary (and
the page I referenced described that). Have you tried either of those
solutions? [if not - give the results in a clarification request to
that question and I'd be glad to work further on it]
--Maniac
|
Clarification of Question by
ga1000-ga
on
12 Feb 2003 20:32 PST
To Maniac-GA
The customer determines the terminal type, and personality of the
terminal. I am not the user. And they have to use the same for their
own reasons.
I will be more than happy to ship the hardware set, device driver
source code (free software under Linux) to you to find the solution.
The fee of course will be adjusted upward to a reasonable level.
|
Clarification of Question by
ga1000-ga
on
12 Feb 2003 20:38 PST
To Maniac-GA
Shipping address can be email to me via our web site, in case you have
the patience and time to tackle this problem.
|
Request for Question Clarification by
maniac-ga
on
13 Feb 2003 04:44 PST
Hello Ga1000,
I understand that customers will use what they have. I also assume
that your equipment works for other customers and their (different)
equipment. If both are true, you have some options related to the
terminal personality and other settings. Let me outline an "typical"
usage of the system:
- user starts using terminal, turning on if needed. At this point we
assume we have terminal settings to login, and they get a shell
prompt. [1]
- user can run other applications, ls, etc.
- user runs a custom application. If custom terminal settings are
needed; the user runs a script (instead of the application directly)
that sets the terminal up [2], runs the application, and resets them
to default after the application quits [1].
- user can run other applications,ls, etc.
- user finishes work, logoff, optional turn terminal off.
[1] The terminal at this point can be set to something that "works"
with your equipment / driver. For example, if VT100's work just fine -
ask the user to set the personality to VT100 as the default.
[2] The terminal at this point is set to what the application needs.
If that is Wyse 60 personality with scrolling disabled, protected
fields, etc. - then fine. Those settings can be done using echo or
perhaps even cat'ing a file to the terminal. It can be undone with the
same method.
As referenced in the original question / clarifications, some of the
sites included techincal notes from vendors indicating how the
terminal should be set up for proper use. Use one of them as an
example in writing up your technical note for your product. This
method would allow the user to work with your equipment *and* operate
their application as needed.
Let me ask another question - for this customer w/ the Wyse 60
terminals - what kind of system do they currently use them on? How are
they set up for that situation (e.g., full RS-232 interface)? Perhaps
there is some feature we can bring from that system to use on Linux
with your equipment?
Another option that just came to mind. You say the driver software is
"free software". Can you provide a link to it so I can compare it with
other serial drivers. There may be something subtle in the way it is
implemented that is causing the problem.
I understand your offer to send the equipment. I am not set up for
that kind of work right now; perhaps another researcher is. However, I
may be able to set something up if we can't work it this way.
--Maniac
|
Clarification of Question by
ga1000-ga
on
13 Feb 2003 08:44 PST
(1) We can not say that the hardware or device driver works in other
applications, because we have not sent them to other places for tests.
But they work in the in-house test like loop back test, or sending and
receiving ASCII characters without the login with the same terminal.
We don't think it is a hardware problem.
(2) The terminal used is actually Wyse150, with Wyse60 'personality'.
Our customer can not use a different type of terminal because their
various customers standardize with this terminal.
(3) There is probably nothing wrong with the customers set up, nor any
problem with the terminal set up. Because the same set up, terminal
work perfect with our own board, an older ISA based board. We can not
tell the customer that to use this new board, they have to change
their settings or terminals, which then cause problems with their
customers.
In other words, the customer wants a board switch from ISA bus to the
PCI bus, while nothing else can be changed.
(4) The RS232 implementation is with three pins only. So software flow
control is necessary.
(5) The current ISA board does not use a special driver. It uses the
RS232.c Linux kernel code which was originated by Linus. That code is
field proven and rock solid. I saw code like adding a LF if a CR is
received, which I do not find in the device driver we use. That may or
may not matter.
(6) Another possiblity is that getty or agetty is meant for rs232.c.
Since I do not have the source code, this is just a speculation.
(7) Files are avaialbe from infooncall.com/serial.c,
infooncall.com/xr17c15x-lnx-pak.tgz, XR17C158v113,pdf. Current ISA
board information is at infooncall.com/rs232.html.
Thank you for your interest.
|
Request for Question Clarification by
duncan2-ga
on
13 Feb 2003 23:58 PST
Hi ga1000,
Since you indicate that the hardware is functional, and the error only
happens under Linux, it seems safe to assume that it's a software
configuration problem.
A logic analyzer probing the pins and recording the actual transaction
would provide the most direct evidence to debug this. Comparing it to
the data from the ISA model might be revealing. That may not be very
practical, however.
Am I correct in assuming that with the same hardware & cabling, but
with the ISA version of the card, the Wyse functions properly?
This may be a shot in the dark, but could you post your settings from
/etc/termcap and/or /usr/lib/terminfo/ ?
Regards,
duncan2-ga
|
Clarification of Question by
ga1000-ga
on
14 Feb 2003 09:04 PST
To Duncan2.ga
(a) The same terminal setting and cabling work perfect with the ISA
board. Since only three pins are used(tx, receive and ground),
software control must be used. Terminal is in fact set at xon xoff.
But I have not found out the code within rs232.c that detects that the
xon xoff is implemented. How does the kernel know that it is software
flow controled, not hardware flow controlled?
(b)The termcap file is posted on infooncall.com/termcap.
It is possible that I did not implement the software control right.
The chip's registers need to be set correctly in order to use xon
xoff. Or the device driver needs some modification.
|
