"man gawk" (for Gawk 5.0) says:


PROCINFO["command", "pty"]
Use a pseudo-tty for two-way communication with
command instead of setting up two one-way pipes.

Prior to that, it says "These variables may be set to control ...", but
doesn't really say what to set them to. Normally, this sort of phrasing implies that setting them to anything - i.e., just causing them to exist - will qualify as "being set".

However, experimentation shows that here, the variable needs to be set to a non-zero value in order to take effect. If is set to 0 or "", it will not
use a pty.

Use the following program to test:

$ gawk 'BEGIN { cmd="tty";PROCINFO[cmd,"pty"];cmd |& getline;print }'
not a tty
$ gawk 'BEGIN { cmd="tty";PROCINFO[cmd,"pty"]=0;cmd |& getline;print }'
not a tty
$ gawk 'BEGIN { cmd="tty";PROCINFO[cmd,"pty"]=1;cmd |& getline;print }' /dev/pts/N

This should either be fixed in the documentation or fixed in the code
(i.e., the code changed so that merely setting it is enough).

--
He must be a Muslim. He's got three wives and he doesn't drink.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01.02.2022 14:15, Kenny McCormack wrote:

"man gawk" (for Gawk 5.0) says:

PROCINFO["command", "pty"]
Use a pseudo-tty for two-way communication with
command instead of setting up two one-way pipes.

Prior to that, it says "These variables may be set to control ...", but doesn't really say what to set them to. Normally, this sort of phrasing implies that setting them to anything - i.e., just causing them to exist - will qualify as "being set".

Just a nitpick...
PROCINFO["command", "pty"] makes it already "exist", just its value
is unset; the predicate (cmd,"pty") in PROCINFO evaluates to true.
Assigning an undefined variable x as in PROCINFO["command", "pty"] = x
will also make it exist, but will still have its value status 'unset'.
If variable x has a defined value then its value is set, but the outcome depends; as you say, values of 0 or "" will not activate the feature.
We have a couple possible states; existing, unset, set, non-null set.
The 'set' state is indeed irrelevant, and using that word misleading,
I agree.

Janis

However, experimentation shows that here, the variable needs to be set to a non-zero value in order to take effect. If is set to 0 or "", it will not use a pty.

Use the following program to test:

$ gawk 'BEGIN { cmd="tty";PROCINFO[cmd,"pty"];cmd |& getline;print }'
not a tty
$ gawk 'BEGIN { cmd="tty";PROCINFO[cmd,"pty"]=0;cmd |& getline;print }'
not a tty
$ gawk 'BEGIN { cmd="tty";PROCINFO[cmd,"pty"]=1;cmd |& getline;print }' /dev/pts/N

This should either be fixed in the documentation or fixed in the code
(i.e., the code changed so that merely setting it is enough).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <stbfeu$7p4$[email protected]>,
Janis Papanagnou <[email protected]> wrote:

On 01.02.2022 14:15, Kenny McCormack wrote:

"man gawk" (for Gawk 5.0) says:


PROCINFO["command", "pty"]
Use a pseudo-tty for two-way communication with
command instead of setting up two one-way pipes.

Prior to that, it says "These variables may be set to control ...", but
doesn't really say what to set them to. Normally, this sort of phrasing
implies that setting them to anything - i.e., just causing them to exist - >> will qualify as "being set".

Just a nitpick...
PROCINFO["command", "pty"] makes it already "exist", just its value

...

The 'set' state is indeed irrelevant, and using that word misleading,
I agree.

Agreed.

The general point of this thread is that it is impossible to figure out
what works (I.e., what you have to do) from the text. You have to resort
to experimentation to figure it out.

For me, the issue is that I use this particular bit of functionality so
rarely that I have to look it up each time, and then end up doing the experiments all over again each time.

--
I am not a troll.
Rick C. Hodgin
I am not a crook.
Rick M. Nixon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01.02.2022 16:05, Kenny McCormack wrote:

The general point of this thread is that it is impossible to figure out
what works (I.e., what you have to do) from the text. You have to resort
to experimentation to figure it out.

For me, the issue is that I use this particular bit of functionality so rarely that I have to look it up each time, and then end up doing the experiments all over again each time.

Absolutely understandable. Myself I had discussions in the past about
map and set semantics implemented by set[value] and map[key] = value respectively. Arnold preferred for the former also set[value] = 1 and
said it's better to use an explicit (but _arbitrary_, non-0) value to
indicate existence, where I prefer a 'key in map' predicate instead.
Such philosophy/thoughts about design lets me usually _assume_ explicit settings of non-null values to activate things in GNU Awk and I am not
too surprised. Notwithstanding should that behavior be reflected by a
proper description. There's no dissent here.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, February 1, 2022 at 8:15:25 AM UTC-5, Kenny McCormack wrote:

"man gawk" (for Gawk 5.0) says:

PROCINFO["command", "pty"]
Use a pseudo-tty for two-way communication with
command instead of setting up two one-way pipes.

I see your point. It does say "the following elements may be SET by a program to
change gawk's behavior" (emphasis mine). And there's similar language in the info docs. I think it's supposed to be implicit that this is evaluated as a typical awk
boolean value, i.e. it's true if it's nonzero or non-null. I tend to agree that the language
could be more explicit.

Also, the info docs include a couple of examples clearly showing the value being
set to 1. So if you look there, you will see how to use it.

If you feel this is a bug, please report it to the gawk bug mailing list. This is
not the ideal forum for reporting bugs.

Regards,
Andy

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)