Author Topic: MeShell problem - start progname inherits stdin/out  (Read 8073 times)

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
MeShell problem - start progname inherits stdin/out
« on: June 30, 2020, 10:40:14 pm »
I have realized now why sometimes starting MeShell fails ("cannot create inpipe...") because a named pipe which has to be closed when closing the last instance of MeShell seems to be still occupied.

The problem occurs if a program has been started via start from MeShell:

[C:\] start e

starts the e Editor in an own session. But it seems that this new session inherits stdout and stdin from the calling cmd.exe process, even it is a PM program, and stdout and stdin are redirected named pipes which are generated when starting MeShell. So when leaving MeShell, the pipes are still occupied while the e Editor is running and MeShell cannot be restarted. After closing the e Editor, you can restart again MeShell. Any idea how to omit inheriting stdin/out/err when starting a program in an own session via Cmd.exe?

Dave Yeo

  • Hero Member
  • *****
  • Posts: 5084
  • Karma: +117/-1
    • View Profile
Re: MeShell problem - start progname inherits stdin/out
« Reply #1 on: July 01, 2020, 03:54:50 am »
Is it
Code: [Select]
start e or
Code: [Select]
"start e" that causes the redirection? Reading the help,
Code: [Select]
help start, it seems to make a difference with the quotation marks causing redirection.

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: MeShell problem - start progname inherits stdin/out
« Reply #2 on: July 01, 2020, 08:06:29 am »
"start e" is not accepted because it it read as a whole word. start "e" makes no difference to start e. I haven't found something about redirection.

I fear that I have to change the pipe name of the new pipe if the default pipe name is occupied, but it won't be a good solution because the internal instance counter (who influences the colors) when running several instances of MeShell has to be increased. MeShell increases the instance number when opening the named pipe fails which contains the instance counter in the filename.
« Last Edit: July 01, 2020, 09:59:16 am by Martin Vieregg »

Laurence Pithie

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +1/-0
    • View Profile
Re: MeShell problem - start progname inherits stdin/out
« Reply #3 on: July 01, 2020, 11:16:44 am »
A program launched using the START command inherits the open file handles of the parent session. The /I parameter to the START command causes the new session to inherit the environment defined by the SET commands in config.sys instead of the CMD.EXE environment of the current session, in which case stdin will point to the keyboard and stdout will point to the monitor and won't be redirected to the pipe.

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: MeShell problem - start progname inherits stdin/out
« Reply #4 on: July 01, 2020, 12:13:12 pm »
Thank you Laurence!

start /I e indeed works fine.

I have implemented a function where MeShell compiles the string before sending it to cmd.exe. When starting an application, MeShell calls DosQueryAppType and if it is a PM program, it changes the call string to
[C:\] start /I mypmprog

But now, the started PM program does not inherited the current directory of cmd.exe anymore. I haven't found a parameter how to enter the current directory. So a call like

START /I e textfile.txt

fails because textfile.txt resides in the current directory an not in C:\. Any idea?


« Last Edit: July 01, 2020, 12:30:54 pm by Martin Vieregg »

Pete

  • Hero Member
  • *****
  • Posts: 1352
  • Karma: +11/-0
    • View Profile
Re: MeShell problem - start progname inherits stdin/out
« Reply #5 on: July 01, 2020, 01:37:27 pm »
Hi Martin

Probably the easiest way would be to add the Drive:\Path to the filename ie

       START /I e Drive:\Path\textfile.txt


Regards

Pete

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: MeShell problem - start progname inherits stdin/out
« Reply #6 on: July 01, 2020, 02:46:55 pm »
Yes, it is an option. But it gets more difficult if there are several parameters. I can compare all parameters with the filenames in the current directory and automatically expand the filenames.

Another option would be to start the app directly from the editor and to send a remark to cmd.exe:

rem e textfile.txt (started via MeShell)

Then, renaming the pipe when failing is still an option. I realized now: Because cmd.exe stdin does not fail (only stdout and sterr is inherited), it will be possible to find out whether the pipe is occupied by a started and still running app or by another MeShell instance.

So I have three options to solve the problem.
« Last Edit: July 01, 2020, 02:53:09 pm by Martin Vieregg »

Laurence Pithie

  • Jr. Member
  • **
  • Posts: 62
  • Karma: +1/-0
    • View Profile
Re: MeShell problem - start progname inherits stdin/out
« Reply #7 on: July 01, 2020, 04:25:25 pm »
Quote
fails because textfile.txt resides in the current directory an not in C:\. Any idea?
Before you issue the start command call  DosQueryPathInfo on the filename, passing FIL_QUERYFULLNAME as the second parameter. The fully qualified path name to the file will be in the buffer you pass as the third parameter You can get the buffer size for the returned full path name from DosQuerySysInfo using the QSV_MAX_PATH_LENGTH as the iStart and iLast parameter.

You'll need to parse the command line to ignore command line parameters and arguments to command line parameters, and deal with cases where more than one filename is passed on the command line.

Martin Vieregg

  • Sr. Member
  • ****
  • Posts: 278
  • Karma: +2/-0
    • View Profile
Re: MeShell problem - start progname inherits stdin/out
« Reply #8 on: July 03, 2020, 11:36:22 pm »
I have chosen now renaming the pipe if the old pipe is still occupied. It was quite complicated, because I already need to count the pipes for several instances of MeShell. I could choose this option because I have the luck that when starting a PM app from cmd.exe, the inpipe is not inherited (because a PM program cannot read keyboard input from an inpipe, but it could create stdout and stderr output). The instances are counted Pipe1, ...Pipe2, Pipe3 for the inpipe and the first free pipe is the instance number which influences colors and default directories. The stdout and stderr pipes ends with A1, A2... If PipeA1 fails for stdout and stderr because it is still occupied from the started PM program, PipeB1 is tried and so on.
It works fine already. So now I have no restrictions at all when starting a PM application and it gets the current directory by default.