Yori script execution

[aleaksunder]

Hi!

There is something with "yori.exe" arguments interpretation... The thing is that there is four parameters on "yori.exe" and when I am trying to combine it something weird going on:

1. If I try to launch yori script with command line something like that:

yori.exe -nouser -c "C:\path\script.ys1"

than nothing happens... it simply starts new yori executable

2. When I try to do otherwise:

yori.exe -c "C:\path\script.ys1" -nouser 

that yori start the script and "-nouser" will be the %1% parameter in this script during execution.

I guess this is due to that code:

yori/sh/main.c

Lines 387 to 405 in 24024b6

	} else if (YoriLibCompareStringWithLiteralInsensitive(&Arg, _T("c")) == 0) {
	if (ArgC > i + 1) {
	*TerminateApp = TRUE;
	StartArgToExec = i + 1;
	ArgumentUnderstood = TRUE;
	break;
	}
	} else if (YoriLibCompareStringWithLiteralInsensitive(&Arg, _T("k")) == 0) {
	if (ArgC > i + 1) {
	*TerminateApp = FALSE;
	StartArgToExec = i + 1;
	ArgumentUnderstood = TRUE;
	break;
	}
	} else if (YoriLibCompareStringWithLiteralInsensitive(&Arg, _T("nouser")) == 0) {
	IgnoreUserScripts = TRUE;
	ArgumentUnderstood = TRUE;
	break;
	} else if (YoriLibCompareStringWithLiteralInsensitive(&Arg, _T("restart")) == 0) {

[malxau]

I think the bug here was the handling of -nouser in that it used break to terminate parsing. Most of these arguments are expected to terminate parsing to allow all future arguments to go to the script (as happened in the second example. The bug is that the first example is expected to work, but -nouser caused parsing to terminate, which is why it ignored the rest and launched a new shell.

[aleaksunder]

Thanks a lot!!!
And there is another issue with script execution. EXIT command simply ignored, this script file will ECHO:

{ any code }
EXIT
ECHO 123

Is there a way to terminate script execution without "GOTO :EOF" statement? Simply just want to make EXIT raising errorlevel, just as CMD does: EXIT /B 1 for example

I can create another issue for this or we may continue here

[malxau]

I tried the script you mention and exit terminated the shell process, so the echo never ran.

I pushed two commits related to this, but I'm not really happy about these behaviors; it seems like there are three different concepts and I'm using two commands to express them:

• Exit shell (with error code)
• End script (with error code)
• End subroutine (with error code)

Previously, Yori had the exit command for the first concept and the return command for the third concept. The second concept could be expressed with goto :eof but as you point out, that makes specifying the error code impossible. I extended the return command to allow for returning from a script, which should be compatible because previously the return statement was undefined when not running from a subroutine. However, this still leaves exiting a script from within a subroutine as inexpressible, and the behavior of return is very different depending on whether a subroutine is active or not. Within a subroutine this will provide isolation (restoring environment and current directory) but from the global scope in a script no isolation is provided.

So what I'd really like is to split return into a second command, but I'm not sure what word to use to express it.

Anyway, commit 2f8ca8d allows exit to specify an exit code and commit ec8e3ad allows return to do something from the global scope of a script.

[aleaksunder]

Recompiled yori with current source... It is more simple to see with that code:

ECHO First
EXIT
ECHO Second
PAUSE

Yes, it exists the script but only after all commands are executed.

For the rest... I think in a nutshell script is nothing more than subroutine for the shell, or maybe just routine, that may have subroutine and RETURN for the script is a very good idea, since it can not only specify exit code but export environment variables in global scope! So if EXIT means to terminate the shell, RETURN means to return something to the shell, it is clear and obvious, and the problem with RETURN for subroutine and RETURN for the script can be solved with for example '-g' switch:

So within subroutine:
RETURN 123 var1 var2 var3 means end subroutine returing exit code 123 and saving vars
RETURN -G 123 var1 var2 var3 means end global routine saving vars
But there is a dillemma... what vars subroutine must save: it's own or var of global routine ( script )
However this is just a variant.

Another variant is new QUIT command for the script, which has identical functionality as RETURN but operates only in script scope.

1. EXIT exits the shell
2. QUIT ends the script
3. RETURN ends the subroutine

Not so bad at first glance, but you're right... there are many variants, it needs more time to decide which is better

[malxau]

I pushed commit 731b036 to ensure that exit from partway through a script terminates script parsing.

What's frustrating about returning from the global scope in a script is it's just so common for CMD scripts to expect their effects to be public, which is why the global scope doesn't (by default) isolate state. This can be done with setlocal and endlocal . I'd agree that isolating state and forcing scripts to declare their intended effects is technically cleaner, but it's very different.

[aleaksunder]

Thanks for quick responses!

P.S. As for me right now feature described in (#58) is most desireble.
Good luck!