Question about the pty option in clispec

General
1

Hi,
The user guide mentioned we can set the pty as false or true for an clispec, could you help explain when the pty could be set to false? My cli could not work after set pty as false.

Thanks.

user guide:
/clispec/$MODE/cmd/callback/exec/options/pty (xs:boolean)
The “pty” element specifies weather a pty should be allocated when executing the
command. The default is to allocate a pty for operational and configure osCommands,
but not for osCommands executing as a pipe command. This behavior can be overridden
with this parameter.

My clispec:

> <operationalMode>
>    <cmd name="shell" mount="start">
>      <info>Open local UNIX shell</info>
>      <help>Open local UNIX shell</help>
>      <callback>
>        <exec>
>          <osCommand>/opt/confd/bin/start_shell</osCommand>
>          <args>$(user)</args>
>          <options>
>            <uid>user</uid>
>            <gid>user</gid>
>            <wd>/flash</wd>
>            <pty>false</pty>
>          </options>
>        </exec>
>      </callback>
>    </cmd>

start_shell is a shell script that will open the bash, it works well when no pty options but after add the false option, the bash could not be started.
The /opt/confd/bin/start_shell as below:

#!/bin/sh
#setup the shell environment
`tty > /tmp/tty.shell`
/bin/bash

I added the tty command before start the shell, the output is “not a tty” after pty option set as false.

2

"p.s The confd-cli command executed from console and the tty is “ttyS0”

4

The pty option can be set to false for non-interactive scripts, i.e. scripts that doesn’t require user input. Scripts can test for the presence of a pty to see if it’s safe to prompt the user for additional input without breaking things.

Your bash example is very much an interactive program and thus requires a pty.

5

Hi[quote=“jjohansson, post:4, topic:822, full:true”]
The pty option can be set to false for non-interactive scripts, i.e. scripts that doesn’t require user input. Scripts can test for the presence of a pty to see if it’s safe to prompt the user for additional input without breaking things.

Your bash example is very much an interactive program and thus requires a pty.
[/quote]

Hi jjohasson, thanks for your reply.
Is there any way we can set the pty to false for an interactive program?

6

I suppose you can wrap your program in script like this:
script -e -c "/bin/bash" /dev/null

It’s not generally recommended to use script(1) in non-interactive shells, though. Furthermore, vi(1) and other interactive programs might create garbage on the screen when run under script.

It’s possible there are other ways to trick interactive programs to think they have stdin but why mess with all this? Why not just use the pty, it takes care of all terminal stuff and interactive programs work as expected.

7

I tried your method, shell could be started but still new pty created for the shell.

The confd-cli

root 16363 16187 0 02:38 ttyS0 00:00:00 /opt/confd/bin/confd_cli -C -u r

From shell

bash-4.2#   PID TTY          TIME CMD
 6121 **pts/5**    00:00:00 bash
 8158 pts/5    00:00:00 ps

Actually we have an interactive program need to be started from confd-cli and that program will check the tty it started from and do different behavior for different tty, that’s why we do not want to create a new pty.