How to create a simple PtTty application with PhAB? (QNX6.3.

[Alain_Achkar1]

Hello,

I want to use PhAB to create a very simple PtTty application. All I
need is to be able to echo characters from another program to it and
read characters from it to the other program.

Example: cat my_file > /dev/ttyp5

I have read all the documentation and I am not sure how to do this.

I started a new Photon application, dragged the PtTty widget to it, and
I set the ‘Pty Dev prefix’ to ‘/dev’. If I try to type ‘/dev/ttyp5’ in
the ‘Device’ box, the PhAB application freezes and the only way out is
to slay it!

I tried to leave the ‘Device’ box empty, but when I save, build, then
run the application, if I do: cat my_file > /dev/ttyp5, nothing appears
on the Tty (which I think is expected, since it does not know what
device name it should open).

Any ideas?
Thanks!
Alain.

[Wojtek_Lerch1]

Alain Achkar wrote:

I want to use PhAB to create a very simple PtTty application. All I
need is to be able to echo characters from another program to it and
read characters from it to the other program.

Here’s the most common way of doing it:

First, you set the “Pty dev prefix” resource (Pt_ARG_TTY_PSEUDO) to
“/dev”, or to NULL. This tells the widget to find and open an unused
pseudo-tty pair. To make sure that it worked, you can then read one of
the FD resources, for instance Pt_ARG_TTY_SFD, and see if it’s changed
from the default -1 to a non-negative value.

Then, you typically ask the PtTty widget to spawn your other program for
you, by setting the Pt_ARG_TTY_CMD or Pt_ARG_TTY_ARGV resource. The
former takes a single string and runs a shell to parse it as a command;
the latter takes an argv vector and runs the specified program directly.
Either way, you can check if it succeeded by getting the
Pt_ARG_TTY_PID resource and seeing if it’s changed from -1 to a
non-negative value.

Example: cat my_file > /dev/ttyp5

I have read all the documentation and I am not sure how to do this.

I started a new Photon application, dragged the PtTty widget to it, and
I set the ‘Pty Dev prefix’ to ‘/dev’. If I try to type ‘/dev/ttyp5’ in
the ‘Device’ box, the PhAB application freezes and the only way out is
to slay it!

The “Device” box (Pt_ARG_TTY_PATH) tells the widget to open the given
path and use the fd for reading and writing, instead of opening the
two ends of a pseudo terminal. Using the same path for your program’s
stdin and stdout causes both the PtTty and your program to try to use
the same end of the pipe for reading and writing, with nothing attached
to the other end. The Pt_ARG_TTY_PATH resource isn’t very useful with
pseudo terminals – it would be a better choice if your goal were to
write a terminal emulator talking to a serial port connected to another
system.

[Alain_Achkar1]

Thanks, this was quite helpful to get me started.

Now, can I tell it which pseudo-tty to use? I prefer not to have the
Photon application spawn the other program, but have the other program
“find” the pseudo tty.

I am actually writing something similar to a terminal emulator, but it
does not connect to a serial port. It should present a path, e.g.
/dev/ttyq1 which the other application would use for input/output. In a
way, it’s similar to starting pterm like this:

pterm -d /dev/ptyq1

and then echoing chars from my application to /dev/ttyq1, e.g.

ls > /dev/ttyq1

It is still not clear to me why Pt_ARG_TTY_PATH returns something like
/dev/ttyp5 and not /dev/ptyp5. The documentation is not clear about
which is master and which is slave? Also, should my terminal emulator
write to /dev/ptyp5 or should it use the Photon functions?

Does QNX supply the code for pterm? (maybe wishful thinking

Thanks!
Alain.

Wojtek Lerch wrote:

Here’s the most common way of doing it:

…
Then, you typically ask the PtTty widget to spawn your other program for
you, by setting the Pt_ARG_TTY_CMD or Pt_ARG_TTY_ARGV resource. The
former takes a single string and runs a shell to parse it as a command;
the latter takes an argv vector and runs the specified program directly.
Either way, you can check if it succeeded by getting the Pt_ARG_TTY_PID
resource and seeing if it’s changed from -1 to a non-negative value.


… The Pt_ARG_TTY_PATH resource isn’t very useful with
pseudo terminals – it would be a better choice if your goal were to
write a terminal emulator talking to a serial port connected to another
system.

[Wojtek_Lerch1]

“Alain Achkar” <js@simplytech.com> wrote in message
news:d2i5te$njr$1@inn.qnx.com…

Thanks, this was quite helpful to get me started.

Now, can I tell it which pseudo-tty to use? I prefer not to have the
Photon application spawn the other program, but have the other program
“find” the pseudo tty.

Of course, you can tell the widget which pseudo-tty to use, by giving it an
fd or a path to open. Just remember that you want the widget to use the
“master” (the /dev/ptypx) and the other program the “slave” (the
/dev/ttypx). The “master” is not a fully functional terminal device.

Of course, you need to make sure that the pseudo-tty isn’t already being
used by a pterm, telnetd, or some other program. One way is to just try –
an attempt to open the master will fail if someone else has it already open.
Another way is by using openpty(). And yet another way is by asking the
PtTty widget to find and open an unused pseudo-tty for you (that’s what the
Pt_ARG_TTY_PSEUDO resource does), reading the Pt_ARG_TTY_PATH resource to
get the path to the slave, and telling the other program to open that path.

I am actually writing something similar to a terminal emulator, but it
does not connect to a serial port. It should present a path, e.g.
/dev/ttyq1 which the other application would use for input/output. In a
way, it’s similar to starting pterm like this:

pterm -d /dev/ptyq1

and then echoing chars from my application to /dev/ttyq1, e.g.

ls > /dev/ttyq1

Or like

ls > $(pterm -N1&)

It is still not clear to me why Pt_ARG_TTY_PATH returns something like
/dev/ttyp5 and not /dev/ptyp5. The documentation is not clear about which
is master and which is slave?

The master is the end that the widget uses to read the other program’s
output from (Pt_ARG_TTY_RFD), and to write Photon keyboard input to
(Pt_ARG_TTY_WFD). The slave is the end that the other program should read
the keyboard input from and write its output to (Pt_ARG_TTY_SFD). The
Pt_ARG_TTY_PATH resource is the path to the slave, rather than the master,
to allow you to pass the path to your other program, in case the other
program wants to open the device itself, instead of being spawned by the
widget and inheriting the fd. The path to the master would be useless to
you – you’re not supposed to try to open it or do any I/O to it.

Which of the above do you think the documentation is not clear enough about?

Also, should my terminal emulator write to /dev/ptyp5 or should it use
the Photon functions?

The PtTty widget will handle writing to and reading from the master. All
you need to do is run PtMainLoop().

Does QNX supply the code for pterm? (maybe wishful thinking >

There isn’t that much code in pterm, and pretty much all of it deals with
parsing command-line arguments, reading and saving the configuration file,
and figuring out what to display on the title bar. Some of the command-line
options correspond directly to the resources of PtTty:

-d – set Pt_ARG_TTY_PATH to
-D – set Pt_ARG_TTY_RFD and Pt_ARG_TTY_WFD to
-N – set Pt_ARG_TTY_PSEUDO, write the Pt_ARG_TTY_PATH string to ,
close
None of the above – set Pt_ARG_TTY_PSEUDO and then Pt_ARG_TTY_ARGV.

Wojtek Lerch wrote:
… The Pt_ARG_TTY_PATH resource isn’t very useful with pseudo
terminals – it would be a better choice if your goal were to write a
terminal emulator talking to a serial port connected to another system.

This didn’t come out quite clear, did it… What I meant was that if you
know you’re using a pseudo-terminal, setting Pt_ARG_TTY_PSEUDO makes your
life easier than setting Pt_ARG_TTY_PATH because it finds an unused pty pair
for you. But after it has found a pty, reading Pt_ARG_TTY_PATH back may be
useful.

[Alain_Achkar1]

It’s all becoming clearer now except for the following:

My tests show that if I start by setting Pt_ARG_TTY_PSEUDO to NULL, then
I read Pt_ARG_TTY_PATH, I get something like: /dev/ttyp4 (slave) which
I can pass to the other program, e.g.

ls > /dev/ttyp4

However, if I start by setting Pt_ARG_TTY_PATH to /dev/ttyp4, it doesn’t
work, i.e.

ls > /dev/ttyp4

will not show up on the TTY widget. Neither does “ls > /dev/ptyp4”.

The only way I was able to make it work is to set Pt_ARG_TTY_PATH to
/dev/ptyp4 and do:

ls > /dev/ttyp4

will show on the TTY widget.

In conclusion, I set Pt_ARG_TTY_PATH to what I want, then I change the
first character from a ‘p’ to a ‘t’ and pass it to the other program.
This is what’s confusing, depending on what you do first, it seems that
Pt_ARG_TTY_PATH contains either the path to the slave or to the master!

Or maybe I’m still missing something?
Alain.


Wojtek Lerch wrote:

“Alain Achkar” <> js@simplytech.com> > wrote in message
news:d2i5te$njr$> 1@inn.qnx.com> …

Thanks, this was quite helpful to get me started.

Now, can I tell it which pseudo-tty to use? I prefer not to have the
Photon application spawn the other program, but have the other program
“find” the pseudo tty.


Of course, you can tell the widget which pseudo-tty to use, by giving it an
fd or a path to open. Just remember that you want the widget to use the
“master” (the /dev/ptypx) and the other program the “slave” (the
/dev/ttypx). The “master” is not a fully functional terminal device.

Of course, you need to make sure that the pseudo-tty isn’t already being
used by a pterm, telnetd, or some other program. One way is to just try –
an attempt to open the master will fail if someone else has it already open.
Another way is by using openpty(). And yet another way is by asking the
PtTty widget to find and open an unused pseudo-tty for you (that’s what the
Pt_ARG_TTY_PSEUDO resource does), reading the Pt_ARG_TTY_PATH resource to
get the path to the slave, and telling the other program to open that path.


I am actually writing something similar to a terminal emulator, but it
does not connect to a serial port. It should present a path, e.g.
/dev/ttyq1 which the other application would use for input/output. In a
way, it’s similar to starting pterm like this:

pterm -d /dev/ptyq1

and then echoing chars from my application to /dev/ttyq1, e.g.

ls > /dev/ttyq1


Or like

ls > $(pterm -N1&)


It is still not clear to me why Pt_ARG_TTY_PATH returns something like
/dev/ttyp5 and not /dev/ptyp5. The documentation is not clear about which
is master and which is slave?


The master is the end that the widget uses to read the other program’s
output from (Pt_ARG_TTY_RFD), and to write Photon keyboard input to
(Pt_ARG_TTY_WFD). The slave is the end that the other program should read
the keyboard input from and write its output to (Pt_ARG_TTY_SFD). The
Pt_ARG_TTY_PATH resource is the path to the slave, rather than the master,
to allow you to pass the path to your other program, in case the other
program wants to open the device itself, instead of being spawned by the
widget and inheriting the fd. The path to the master would be useless to
you – you’re not supposed to try to open it or do any I/O to it.

Which of the above do you think the documentation is not clear enough about?


Also, should my terminal emulator write to /dev/ptyp5 or should it use
the Photon functions?


The PtTty widget will handle writing to and reading from the master. All
you need to do is run PtMainLoop().


Does QNX supply the code for pterm? (maybe wishful thinking >


There isn’t that much code in pterm, and pretty much all of it deals with
parsing command-line arguments, reading and saving the configuration file,
and figuring out what to display on the title bar. Some of the command-line
options correspond directly to the resources of PtTty:

-d – set Pt_ARG_TTY_PATH to <path
-D – set Pt_ARG_TTY_RFD and Pt_ARG_TTY_WFD to <fd
-N – set Pt_ARG_TTY_PSEUDO, write the Pt_ARG_TTY_PATH string to ,
close <fd
None of the above – set Pt_ARG_TTY_PSEUDO and then Pt_ARG_TTY_ARGV.


Wojtek Lerch wrote:

… The Pt_ARG_TTY_PATH resource isn’t very useful with pseudo
terminals – it would be a better choice if your goal were to write a
terminal emulator talking to a serial port connected to another system.


This didn’t come out quite clear, did it… What I meant was that if you
know you’re using a pseudo-terminal, setting Pt_ARG_TTY_PSEUDO makes your
life easier than setting Pt_ARG_TTY_PATH because it finds an unused pty pair
for you. But after it has found a pty, reading Pt_ARG_TTY_PATH back may be
useful.

[Alain_Achkar1]

Hello,

1. If my PtTTY widget has 40 columns and I send 40 characters to it, the
   cursor wraps to the next line. In ANSI terminals, there is a way to
   disable this AUTOWRAP feature. How do I do it with PtTTY or pterm?

Quoting from PtTerminal docs:

Pt_ARG_TERM_OPTIONS
C type Pt type Default
unsigned long Flag 0x84380

A set of flags that can be set or cleared by escape sequences. The flags
are numbered from 1 to 32 (see <photon/PtTerm.h>). The widget handles
some of them, and your application can handle some others.

Pt_ARG_TERM_OPTMASK
C type Pt type Default
unsigned long Flag ~0uL

A set of bits that correspond to those in Pt_ARG_TERM_OPTIONS. Clearing
a bit in Pt_ARG_TERM_OPTMASK disables the escape sequence for the
corresponding bit in Pt_ARG_TERM_OPTIONS

2. Also, which ESC sequences are handled by the widget and which should
   be handed by my application?

3. When I send the following:

ESC [ > 14 h

…the Pt_ARG_TERM_OPTIONS changes from the default 0x84380 to 0x86380,
however the PtTTY still autowraps chars.

When I send:

ESC [ > 14 l

…the Pt_ARG_TERM_OPTIONS changes from the 0x86380 back to 0x84380,
however the PtTTY still autowraps chars.

Note: 14 is the constant defined in PtTerm.h for Pt_TERM_ALLOW_AUTOWRAP:

/*

• Pt_TERM_OPTIONS bit numbers.
• Set by the escape sequences:
• in QNX emulation “\33/>#h” sets option #
• in ANSI emulation “\33[>#h” sets option #
  */
  #define Pt_TERM_REPORT_CLICKS 1
  #define Pt_TERM_REPORT_RESIZE 2
  …
  #define Pt_TERM_ALLOW_AUTOSCROLL 13
  #define Pt_TERM_ALLOW_AUTOWRAP 14
  #define Pt_TERM_ALLOW_AUTOSELECT 15

Thanks!
Alain.

[Wojtek_Lerch1]

“Alain Achkar” <js@simplytech.com> wrote in message
news:d2khkr$hto$1@inn.qnx.com…

It’s all becoming clearer now except for the following:

My tests show that if I start by setting Pt_ARG_TTY_PSEUDO to NULL, then I
read Pt_ARG_TTY_PATH, I get something like: /dev/ttyp4 (slave) which I can
pass to the other program, e.g.

ls > /dev/ttyp4

Yes. Pt_ARG_TTY_PSEUDO finds and opens two devices – the master and the
slave of a pseudo-tty pair. The purpose of this resource is to have the
widget talk to the master, and something else, most likely another program,
talk to the slave. That’s how a pseudo-tty is meant to be used: you run
some program on the slave end, and whatever it writes to the slave is
avaliable for reading from the master. The PtTty widget reads it and
displays on the screen. The reason the Pt_ARG_TTY_PATH string is set to to
the pathname of the slave, rather than of the master, is to let you give it
to the other program, in case that program wants a pathname rather than an
already opened fd.

However, if I start by setting Pt_ARG_TTY_PATH to /dev/ttyp4, it doesn’t
work, i.e.

ls > /dev/ttyp4

will not show up on the TTY widget. Neither does “ls > /dev/ptyp4”.

Right. When you set Pt_ARG_TTY_PATH to a pathname, the widget just opens
that pathname and talks to the resulting fd, without worrying about whether
it’s a master or a slave of a pseudo-tty or some other kind of a device. If
it were a serial port, you could connect another computer to the other end
of the wire, and use the PtTty widget as a terminal to run programs on the
other computer. By setting Pt_ARG_TTY_PATH rather than Pt_ARG_TTY_PSEUDO,
you’re telling the widget not to worry about the other end of the wire. For
it to be useful, you need to know what the other end on the wire is, and
whether some program or maybe a piece of hardware is already talking to it
or needs to be started, and how.

What you’re doing in this example is connecting both the PtTty widget and
the stdout of ls to the same end of a pseudo-tty, and leaving the other end
disconnected. The output from ls ends up stuck in the pipe because there’s
nobody to read it from the other end.

The only way I was able to make it work is to set Pt_ARG_TTY_PATH to
/dev/ptyp4 and do:

ls > /dev/ttyp4

will show on the TTY widget.

Yes; you’re basically mimicking what setting the Pt_ARG_TTY_PSEUDO resource
does: it opens the two ends of the pseudo-tty, so that the widget can talk
to the master and someone else to the slave.

In conclusion, I set Pt_ARG_TTY_PATH to what I want, then I change the
first character from a ‘p’ to a ‘t’ and pass it to the other program.

That’s because you know how the names of the master and the slave of a
pseudo-tty are related to each other under QNX. A somewhat more portable
way would be to use the openpty() function and then give the master fd to
the PtTty widget and the slave fd or pathname to the other program.
(Incidentally, that’s exactly what the widget does when you set the
Pt_ARG_TTY_PSEUDO resource.)

This is what’s confusing, depending on what you do first, it seems that
Pt_ARG_TTY_PATH contains either the path to the slave or to the master!

Or to a serial port, or some other device. Depending on whether you have
set Pt_ARG_TTY_PATH or Pt_ARG_TTY_PSEUDO, reading Pt_ARG_TTY_PATH back
returns either what you have set it to or what you asked the widget to find
for you. Setting Pt_ARG_TTY_PSEUDO tells the widget, “find a pseudo tty and
open both ends of it and tell me the name of the end I need to talk to”.
Setting Pt_ARG_TTY_PATH tells the widget, “just open this and talk to it,
and remember the path in case I ask for it”. It’s a big difference.

[Wojtek_Lerch1]

The escape sequence you’re looking for is ESC [ ? 7 l (and ESC [ ? 7 h to
switch wrapping back on). The documentation of devc-con contains a few
tables describing other useful escape sequences.

“Alain Achkar” <js@simplytech.com> wrote in message
news:d2kvb3$qle$1@inn.qnx.com…

Hello,

1. If my PtTTY widget has 40 columns and I send 40 characters to it, the
   cursor wraps to the next line. In ANSI terminals, there is a way to
   disable this AUTOWRAP feature. How do I do it with PtTTY or pterm?

Quoting from PtTerminal docs:

Pt_ARG_TERM_OPTIONS
C type Pt type Default
unsigned long Flag 0x84380

A set of flags that can be set or cleared by escape sequences. The flags
are numbered from 1 to 32 (see <photon/PtTerm.h>). The widget handles some
of them, and your application can handle some others.

Pt_ARG_TERM_OPTMASK
C type Pt type Default
unsigned long Flag ~0uL

A set of bits that correspond to those in Pt_ARG_TERM_OPTIONS. Clearing a
bit in Pt_ARG_TERM_OPTMASK disables the escape sequence for the
corresponding bit in Pt_ARG_TERM_OPTIONS

2. Also, which ESC sequences are handled by the widget and which should be
   handed by my application?

3. When I send the following:

ESC [ > 14 h

…the Pt_ARG_TERM_OPTIONS changes from the default 0x84380 to 0x86380,
however the PtTTY still autowraps chars.

When I send:

ESC [ > 14 l

…the Pt_ARG_TERM_OPTIONS changes from the 0x86380 back to 0x84380,
however the PtTTY still autowraps chars.

Note: 14 is the constant defined in PtTerm.h for Pt_TERM_ALLOW_AUTOWRAP:

/*

• Pt_TERM_OPTIONS bit numbers.
• Set by the escape sequences:
• in QNX emulation “\33/>#h” sets option #
• in ANSI emulation “\33[>#h” sets option #
  */
  #define Pt_TERM_REPORT_CLICKS 1
  #define Pt_TERM_REPORT_RESIZE 2
  …
  #define Pt_TERM_ALLOW_AUTOSCROLL 13
  #define Pt_TERM_ALLOW_AUTOWRAP 14
  #define Pt_TERM_ALLOW_AUTOSELECT 15

Thanks!
Alain.

[Alain_Achkar1]

Thanks! Your escape sequence worked.

I don’t know why the TTY docs refer to PtTerm.h with different escape
sequences. Maybe the TTY docs need to be updated?


Wojtek Lerch wrote:

The escape sequence you’re looking for is ESC [ ? 7 l (and ESC [ ? 7 h to
switch wrapping back on). The documentation of devc-con contains a few
tables describing other useful escape sequences.

“Alain Achkar” <> js@simplytech.com> > wrote in message
news:d2kvb3$qle$> 1@inn.qnx.com> …

Hello,

1. If my PtTTY widget has 40 columns and I send 40 characters to it, the
   cursor wraps to the next line. In ANSI terminals, there is a way to
   disable this AUTOWRAP feature. How do I do it with PtTTY or pterm?

Quoting from PtTerminal docs:

Pt_ARG_TERM_OPTIONS
C type Pt type Default
unsigned long Flag 0x84380

A set of flags that can be set or cleared by escape sequences. The flags
are numbered from 1 to 32 (see <photon/PtTerm.h>). The widget handles some
of them, and your application can handle some others.

Pt_ARG_TERM_OPTMASK
C type Pt type Default
unsigned long Flag ~0uL

A set of bits that correspond to those in Pt_ARG_TERM_OPTIONS. Clearing a
bit in Pt_ARG_TERM_OPTMASK disables the escape sequence for the
corresponding bit in Pt_ARG_TERM_OPTIONS

2. Also, which ESC sequences are handled by the widget and which should be
   handed by my application?

3. When I send the following:

ESC [ > 14 h

…the Pt_ARG_TERM_OPTIONS changes from the default 0x84380 to 0x86380,
however the PtTTY still autowraps chars.

When I send:

ESC [ > 14 l

…the Pt_ARG_TERM_OPTIONS changes from the 0x86380 back to 0x84380,
however the PtTTY still autowraps chars.

Note: 14 is the constant defined in PtTerm.h for Pt_TERM_ALLOW_AUTOWRAP:

/*

• Pt_TERM_OPTIONS bit numbers.
• Set by the escape sequences:
• in QNX emulation “\33/>#h” sets option #
• in ANSI emulation “\33[>#h” sets option #
  */
  #define Pt_TERM_REPORT_CLICKS 1
  #define Pt_TERM_REPORT_RESIZE 2
  …
  #define Pt_TERM_ALLOW_AUTOSCROLL 13
  #define Pt_TERM_ALLOW_AUTOWRAP 14
  #define Pt_TERM_ALLOW_AUTOSELECT 15

Thanks!
Alain.


\

[Alain_Achkar1]

Thank you Wojtek!

It is all very clear to me now! I understand it fully, and I have many
options to choose from, depending on my requirement.

Alain.

Wojtek Lerch wrote:

“Alain Achkar” <> js@simplytech.com> > wrote in message
news:d2khkr$hto$> 1@inn.qnx.com> …

It’s all becoming clearer now except for the following:

My tests show that if I start by setting Pt_ARG_TTY_PSEUDO to NULL, then I
read Pt_ARG_TTY_PATH, I get something like: /dev/ttyp4 (slave) which I can
pass to the other program, e.g.

ls > /dev/ttyp4


Yes. Pt_ARG_TTY_PSEUDO finds and opens two devices – the master and the
slave of a pseudo-tty pair. The purpose of this resource is to have the
widget talk to the master, and something else, most likely another program,
talk to the slave. That’s how a pseudo-tty is meant to be used: you run
some program on the slave end, and whatever it writes to the slave is
avaliable for reading from the master. The PtTty widget reads it and
displays on the screen. The reason the Pt_ARG_TTY_PATH string is set to to
the pathname of the slave, rather than of the master, is to let you give it
to the other program, in case that program wants a pathname rather than an
already opened fd.


However, if I start by setting Pt_ARG_TTY_PATH to /dev/ttyp4, it doesn’t
work, i.e.

ls > /dev/ttyp4

will not show up on the TTY widget. Neither does “ls > /dev/ptyp4”.


Right. When you set Pt_ARG_TTY_PATH to a pathname, the widget just opens
that pathname and talks to the resulting fd, without worrying about whether
it’s a master or a slave of a pseudo-tty or some other kind of a device. If
it were a serial port, you could connect another computer to the other end
of the wire, and use the PtTty widget as a terminal to run programs on the
other computer. By setting Pt_ARG_TTY_PATH rather than Pt_ARG_TTY_PSEUDO,
you’re telling the widget not to worry about the other end of the wire. For
it to be useful, you need to know what the other end on the wire is, and
whether some program or maybe a piece of hardware is already talking to it
or needs to be started, and how.

What you’re doing in this example is connecting both the PtTty widget and
the stdout of ls to the same end of a pseudo-tty, and leaving the other end
disconnected. The output from ls ends up stuck in the pipe because there’s
nobody to read it from the other end.


The only way I was able to make it work is to set Pt_ARG_TTY_PATH to
/dev/ptyp4 and do:

ls > /dev/ttyp4

will show on the TTY widget.


Yes; you’re basically mimicking what setting the Pt_ARG_TTY_PSEUDO resource
does: it opens the two ends of the pseudo-tty, so that the widget can talk
to the master and someone else to the slave.


In conclusion, I set Pt_ARG_TTY_PATH to what I want, then I change the
first character from a ‘p’ to a ‘t’ and pass it to the other program.


That’s because you know how the names of the master and the slave of a
pseudo-tty are related to each other under QNX. A somewhat more portable
way would be to use the openpty() function and then give the master fd to
the PtTty widget and the slave fd or pathname to the other program.
(Incidentally, that’s exactly what the widget does when you set the
Pt_ARG_TTY_PSEUDO resource.)


This is what’s confusing, depending on what you do first, it seems that
Pt_ARG_TTY_PATH contains either the path to the slave or to the master!


Or to a serial port, or some other device. Depending on whether you have
set Pt_ARG_TTY_PATH or Pt_ARG_TTY_PSEUDO, reading Pt_ARG_TTY_PATH back
returns either what you have set it to or what you asked the widget to find
for you. Setting Pt_ARG_TTY_PSEUDO tells the widget, “find a pseudo tty and
open both ends of it and tell me the name of the end I need to talk to”.
Setting Pt_ARG_TTY_PATH tells the widget, “just open this and talk to it,
and remember the path in case I ask for it”. It’s a big difference.
\