Custom command line interpreter

Things you’d like to miss in the future...
admin
Site Admin
Posts: 60288
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: Custom command line interpreter

Post by admin »

This works:

Code: Select all

!ls;pause

TheQwerty
Posts: 4373
Joined: 03 Aug 2007 22:30

Re: Custom command line interpreter

Post by TheQwerty »

admin wrote:I will re-add /k and /c for cmd.exe. That should do, right?
Well it works for me, but the more I think about this the more I wonder about what's correct.

I'm currently thinking the best might be:
1) Remove the /k|/c smartness from XY.
2) Migrate the existing settings from (this is from memory so forgive my errs):

Code: Select all

[x] Custom Interpreter 
Exe: [cmd.exe]
Args: [-custom -args <command>]
to:

Code: Select all

Interpreter:
!: ["cmd.exe" -custom -args <command>]
!!: ["cmd.exe" -custom -args <command>]
The defaults would actually be:

Code: Select all

!: ["%comspec%" /k <command>]
!!: ["%comspec%" /c <command>]

The cons:
- User may need to edit both settings instead of just one.
- Documentation needs updated.
- Translations need performed.
- Combining the two fields might cause confusion, but having the same level of flexibility would otherwise require 4 fields.

The pros:
- More user options: ! and !! can be different shells, the user can switch which leaves the console visible.
- The smartness is removed from XY and thus cannot create more problems.
- Eh, not sure what else, possibly means less code in XY?

:eh:

EDIT: Note that I haven't actually tried. *.0309 yet.

admin
Site Admin
Posts: 60288
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: Custom command line interpreter

Post by admin »

Looks good. But I personally never use custom command line interpreters so I'm not the best man to decide.

And here is another Con:
- Potentially breaks old user code.

nerdweed
Posts: 648
Joined: 25 Feb 2012 07:47

Re: Custom command line interpreter

Post by nerdweed »

Another option would be to remove the short name fixes entirely :ninja: . Everything works there apart from short names.

admin
Site Admin
Posts: 60288
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: Custom command line interpreter

Post by admin »

What does not work?

nerdweed
Posts: 648
Joined: 25 Feb 2012 07:47

Re: Custom command line interpreter

Post by nerdweed »

Code: Select all

*.0300 
Short names do not work, so they are out here.

Default command line
! -> opens command prompt - Good
!! -> opens and closes command prompt - Good
!dir -> open command prompt with directory listing - Good
!!dir -> open command prompt with directory listing and closes - Good

%winsysnative%\WindowsPowerShell\v1.0\powershell.exe
! -> opens powershell - Good
!! -> opens powershell  - OK
!dir -> opens powershell with listing and closes - Should have stayed open - Bad
!!dir -> opens powershell with listing and closes - Should have stayed open - Good
*.0309

Code: Select all

Default command line is in line with *.0300 -> Good

Short name (powershell)
! -> Doesn't seem to do anything, but maybe it opens and closes - Should have remained open - Bad
!! -> Doesn't seem to do anything, but maybe it opens and closes - Good
!dir -> Opens powershell with listing and closes - Should have stayed open - Bad
!!dir -> Opens powershell with listing and closes - Good

Full path (%winsysnative%\WindowsPowerShell\v1.0\powershell.exe)
! -> Opens powershell - Good
!! -> Open powershell - OK
!dir -> Opens powershell - Bad (Should have done a directory listing as well)
!!dir -> Opens powershell - Bad (Should have done a directory listing and closed)
So, it wasn't perfect even during *.0300 (so my previous post about undoing the changes was nonsense)

And besides this, there is a small issue in general. The command prompt doesn't open up with a ! when in this computer (or other location that command prompt cannot show). I believe it should open up at the documents folder instead.

admin
Site Admin
Posts: 60288
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: Custom command line interpreter

Post by admin »

Whether a custom command line interpreter stays open or not, or how to control this via command line, cannot be the job of XY. You have to pass the necessary commands as arguments.
nerdweed wrote:And besides this, there is a small issue in general. The command prompt doesn't open up with a ! when in this computer (or other location that command prompt cannot show). I believe it should open up at the documents folder instead.
Hm, why the documents folder? And why is this a problem? I think the current behavior is totally OK. No need for extra smartness.

Let's close this topic for now. At least me I have to turn to other more important things now.

nerdweed
Posts: 648
Joined: 25 Feb 2012 07:47

Re: Custom command line interpreter

Post by nerdweed »

I agree.

TheQwerty
Posts: 4373
Joined: 03 Aug 2007 22:30

Re: Custom command line interpreter

Post by TheQwerty »

*bump*

Exploring the state again today (in fresh v17.50.0100) it seems worse than I remember.

Case 1: User specifies short name for CCLI and no custom arguments:
<xyini> wrote:CustomCLI=powershell
CustomCLIArgs=
'!' - Does nothing.
'!dir' - CreateProcess with cmdLine containing module and <command> - powershell's behavior is to execute command and exit, so OK.
'!!dir' - Same as '!dir'.

I'd imagine this would be a user's first attempt to swap in PowerShell as a replacement and will be frustrating.

Case 2: User specifies full path for CCLI and no custom arguments:
<xyini> wrote:CustomCLI=%winsysnative%\WindowsPowerShell\v1.0\powershell.exe
CustomCLIArgs=
'!' - CreateProcess with cmdLine containing module only - correctly opens powershell.
'!dir' & '!!dir' - CreateProcess without module in cmdLine - powershell ignores first argument (our command) making these the same as '!'.
'!dir dir' & '!!dir dir' - CreateProcess with cmdLine "dir dir" - powershell ignores first argument, executes second, and exits.

Per Microsoft this is '"abnormal" behavior':
NOTE: ANSI specifications require that argv[0] should be equal to the application name, but CreateProcess gives the calling application the flexibility to override this rule for 32-bit processes.
Case 3: User specifies full path for CCLI and custom arguments:
<xyini> wrote:CustomCLI=%winsysnative%\WindowsPowerShell\v1.0\powershell.exe
CustomCLIArgs=-NoExit -Command "<command>"
'!' - CreateProcess with cmdLine containing module only - correctly opens powershell.
'!dir' & '!!dir' - CreateProcess without module in cmdLine - powershell ignores '-NoExit', executes second argument, and exits.
'!dir dir' & '!!dir dir' - Similar to single 'dir' versions because powershell will still ignore '-NoExit'.

Case 4: User specifies full path for CCLI and custom arguments including a module name:
<xyini> wrote:CustomCLI=%winsysnative%\WindowsPowerShell\v1.0\powershell.exe
CustomCLIArgs=powershell.exe -NoExit -Command "<command>"
'!' - CreateProcess with cmdLine containing module only - correctly opens powershell.
'!dir' & '!!dir' - CreateProcess with cmdLine containing user's specified module - thus correctly opens powershell, executes 'dir' and stays open.

At this point the user might be satisfied if they don't mind '!' and '!!' both doing the same thing, otherwise I'd imagine they'd just give up and use aliases to get the desired behavior.

I understand that the "problem" is in some part the called program for ignoring argv[0] but I believe the true culprit is XY not following the (confusing) convention in this instance (XY does it right in other places).

Again I think the only reasonable way forward is to separate the configuration as I said previously (quoted below). This also has the added benefit of allowing you to pass NULL for the application name and only make use of the command line parameter which lessens the above-mentioned confusion.
TheQwerty wrote:
admin wrote:I will re-add /k and /c for cmd.exe. That should do, right?
Well it works for me, but the more I think about this the more I wonder about what's correct.

I'm currently thinking the best might be:
1) Remove the /k|/c smartness from XY.
2) Migrate the existing settings from (this is from memory so forgive my errs):

Code: Select all

[x] Custom Interpreter 
Exe: [cmd.exe]
Args: [-custom -args <command>]
to:

Code: Select all

Interpreter:
!: ["cmd.exe" -custom -args <command>]
!!: ["cmd.exe" -custom -args <command>]
The defaults would actually be:

Code: Select all

!: ["%comspec%" /k <command>]
!!: ["%comspec%" /c <command>]

Post Reply