lib to check init.bat's custom args

[xiazeyu]

This commit deals with the issue when I tried to use init.bat for both cmder.exe and Code.exe (VS Code).
in the user-profile, I set an Autorun function:

set Option1=%1
if not "%Option1%" == "noAutoRun" (
  echo Auto run
  call devDocs
  call SublimeText
  call vsCode
)

In cmder.exe, these applications will be run once I start cmder.exe,
and will not run when I use it in VSCode

"terminal.integrated.shell.windows": "cmd.exe",
  "terminal.integrated.shellArgs.windows": [
    "/k",
    "%cmder_root%/vendor/init.bat",
    "noAutoRun"
  ]

to achieve this, I passed the arguments received by init.bat to user-profile.cmd and it seems OK.

[daxgames]

This should be handled differently. init.bat already accepts named args that could break your intended use case. Maybe an else in the init.bat command parser code that adds all unrecognized arguments to a CMDER_FLAGS environment variable:

else (
  set "CMDER_FLAGS=%CMDER_FLAGS% %1"
}

That can be passed to `user-profile.cmd:

set "initialConfig=%CMDER_ROOT%\config\user-profile.cmd"
if exist "%CMDER_ROOT%\config\user-profile.cmd" (
    REM Create this file and place your own command in there
    call "%CMDER_ROOT%\config\user-profile.cmd" %CMDER_FLAGS%
)

if defined CMDER_USER_CONFIG (
  set "initialConfig=%CMDER_USER_CONFIG%\user-profile.cmd"
  if exist "%CMDER_USER_CONFIG%\user-profile.cmd" (
      REM Create this file and place your own command in there
      call "%CMDER_USER_CONFIG%\user-profile.cmd" %CMDER_FLAGS%
  )
)

user-profile.cmd could then do something like:

echo %* | find -i "/noautorun"
if "%ERRORLEVEL%" == "1" (
  echo Auto run
  call devDocs
  call SublimeText
  call vsCode
)

If OK with other @cmderdev/trusted-contributors .

[xiazeyu]

@daxgames Sorry that I've missed init.bat's built-in command parser
Now I've fixed it by using %CMDER_FLAGS% and added notes in user-profile.cmd

By the way, it seems that v1.3.5 isn't match current branch at all. Is that OK?

[daxgames]

@xiazeyu - Yes 1.3.5 is the released version of cmder. The master branch has unreleased changes. Also I made a couple more small changes just to make things a little clearer.

@cmderdev/trusted-contributors do you approve of this change?

[DRSDavidSoft]

is vsCode a batch file, or a subroutine? Why is it called here?

[daxgames]

It's not it's a comment

[xiazeyu]

@DRSDavidSoft
vsCode itself is an alias which I used to run vsCode.
I put here just to show an realistic example, it can be replaced by anything.

It is possible that the user may feel confused with what it is, like you did, but I does'nt have a clear idea of what to write here yet.

[xiazeyu]

@daxgames @DRSDavidSoft I've optimize the comments about this feature, have a look plz.

[Stanzilla]

@daxgames ready to merge or nah?

[DRSDavidSoft]

• This functionality should be documented in README.md, please add a commit which includes your description. @xiazeyu
• I think the argument handling should be done using one of the recently added libraries. lib_base.bat, perhaps? @daxgames
• Also, I think plugins should be called from the config directory, maybe user-plugins.bat? If possible, init.bat should call that file with the appropriate library already parsed. My reasoning is that init.bat gets overwritten on each update, thus not a reliable location for plugins.

[DRSDavidSoft]

P.S. 1

@daxgames I can write a lib_arguments.bat to parse the arguments, If it's okay by you. It should parse these types of switches IMO:

• /switch
• --switch
• -s and/or /s

P.S. 2

@xiazeyu On another note, we have a Wiki page explaining on how to integrate Cmder with VS Code, here: https://github.com/cmderdev/cmder/wiki/Seamless-VS-Code-Integration

If you have something useful in your vsCode.bat, we'd appreciate posting it there.

Here's also the wiki page for Sublime 3 integration: https://github.com/cmderdev/cmder/wiki/Seamless-Sublime-Text-3-Integration

[daxgames]

@DRSDavidSoft I don't understand the argument handling question and I don't understand the plugins comment because there is no argument handling because any unknown argument to is just passed to user-profile.cmd and there are no plugins so can you explain?

[DRSDavidSoft]

@daxgames Sure. I propose adding a simple wrapper to be used as argument handler, instead of find /i'ing and comparing the produced error level each time. Something like this:

REM place `user-plugins.bat` functions here

:exampleFunction
    echo. Something is executed!
    exit /b

:anotherFunction
    echo. Something else is being executed!
    exit /b

REM this section should be called from either `init.bat` or `user-profile.bat`

call :conditionalCall switchname1 exampleFunction
call :conditionalCall switchname2 anotherFunction

REM this section goes into `lib_args.bat` or `lib_base.bat`, etc

:conditionalCall 
    set arg_name=%1
    set subroutine_name=%2

    call :matchArgument %arg_name% %CMDER_FLAGS%
    if "%ERRORLEVEL%" == "0" call :%subroutine_name%

    exit /b

Of course, this is just an idea. If this doesn't make any sense, let's ommit it and stick to parsing arguments directly in user-profile.bat

My other main point (regarding documentation) is that this functionality (and how to use it with user-profile.bat) should be addressed in README.md.

[xiazeyu]

@DRSDavidSoft

I think document this function in README.md is a good idea.

In my vsCode.cmd, there's nothing but a call %cmder_root%/bin/vsCode/code.exe. I use cmder as an entry point of my working environment, so I'd better to have some commands to shell these editors with UI, not intergrade cmder into them, and that's what my vsCode.cmd for. Type vsCode, and I can shell vs cofe, and not interrupt my current console job.

I think your wapper idea is excellent, that will make user-profile.cmd much better readable and clear. It's a good alternative to simple switch jobs(it can't replace those more complicated jobs which may process more than 1 argument eg. /setEnv development).

I also think it will be too much complex if uder-profile.cmd has too much, and add more file may make it bloated.

I will try if I can put this function into something like have.cmd, and it will just work similarly to the useage of alias.cmd. How ever automatically pass %CMDER_FLAGS% to have.cmd and **ability to call sub functions(like your :exampleFunction and :anotherFunction in user-profile.cmd) needs some research.

[DRSDavidSoft]

@xiazeyu Glad to hear that, so I'll wait to see what you'll commit for the mentioned subroutines.
Also, could you make the README commit in this same PR?

If you need help, you can count on me. I think this functionality will be great in Cmder! :)

[xiazeyu]

@DRSDavidSoft @daxgames @Stanzilla I've done my work, and have a look if this have something unexpected.

I recommend to update the Wiki page when the PR is merged.

[daxgames]

@xiazeyu Cmder has a concept of importable libraries in vendor\lib this is what @DRSDavidSoft was referring to when he suggested a 'lib_arguments.bat to parse the arguments'. I like what you have done mostly. I am hoping you can refactor your code using the files in vendor\lib as examples.

We put the libraries in vendor\lib because they should not be edited by users of cmder. Your have method if it is to be a part of cmder should not be edited by users so it should not be in %cmder_root%\bin. Eventually I would even like to move the alias.bat out of %cmder_root%\bin into a library in vendor\lib for this same reason.

I am not sure I like have as the method name, I am thinking flag_exists as the method that checks if a flag is set and flag_exists not could check for the absence of the flag.

Thoughts?

[xiazeyu]

@daxgames See the latest commit.
I agree with you to put these kind of scripts into vendor\lib to prevent users to edit them.
(My production environment is using v1.3.5 so I've missed your vendor\lib change.)
However, I think always using %flag_exists% xxx xxx is not that concise, maybe alias it or put it into %PATH% a better idea, since users don't use %lib_git% quite often, but %flag_exists% is directly used by users.

I'm poor at naming functions, so I really think flag_exists is a better idea.

[DRSDavidSoft]

@daxgames, thoughts?

@xiazeyu I'm reviewing the PR, if everything's alright I'll ask @Stanzilla to merge it.

Thanks for the contribution, btw!

[xiazeyu]

@DRSDavidSoft @daxgames @Stanzilla
By the way, is it possible to let me know when will the next stable version be released?

[daxgames]

We just released 1.3.6. It has a couple of issues that have already been fixed. I think we might need to do another one sooner rather than later.

[xiazeyu]

These concerns are just about some style issue, and since it can work, I don't think it matters a lot.

[DRSDavidSoft]

Personally I have these issues in mind:
1- Should Cmder.exe pass the flag to init.bat?
2- The code for flag_exists.cmd library needs a bit of refactoring
3- The readme notes require more intuitive explanation and better formatting

[DRSDavidSoft]

Some more questions

[DRSDavidSoft]

@xiazeyu Please have a look at my review; once you reply them I can make a PR to your branch to address them.

Some additional points:

• If the flags are not passed from the launcher (Cmder.exe), I'll write the required code to make it happen. I think it will be useful to have both launcher and init.bat able to set flags.
  • Update: as @daxgames suggested, prefixed with /uflags. Possibly done in another PR.
• A better suggestion for the title: "Passing custom flags to Cmder and handling them in user-profile.cmd"
• Also, I think this feature deserves its own page in the Wiki, instead of a section in the VS Code. (I know you mainly use it in combination with VS Code, but it can also be used in combination with Sublime and other IDEs, Terminals.)
• I think the more of the docs and help/usage be placed in the Wiki is the better.

[xiazeyu]

I passed to init.bat because I need to use it with no launcher in vsCode.
things like cmder.exe /cpp or cmder.exe /nodejs or cmder.exe /python may be useful to those who need to initialize multi-environments but are to slow to start up.
I don't know if Sublime also have internal terminal or othre things. Things like wiki(or documents) you can write as you want. Since I recently don't have a lot of time to dealing with such documents.(also not good at it).

Thanks for your idea and review anyway.

[DRSDavidSoft]

@xiazeyu Thanks for the quick replies.

I'll commit my suggested edits and then make a PR into your branch before this one is merged.

Might I suggest making this new flag feature work when called from both init.bat and Cmder.exe to make it unified? Personally I only use init.bat, but that's for power users like you and me. The regular users will stick to Cmder.exe and I think adding your feature also to the main launcher will greatly benefit them.

Also, @daxgames, your thoughts please.

[xiazeyu]

I'm totally agree with you.
Look forward to your commits.

[daxgames]

@DRSDavidSoft and @xiazeyu I am not sure we need to add this functionality to cmder.exe, I am not sure I understand why its needed. The stated use case is to run init.bat /noautorun in a shell from another tool not running cmder.exe /noautorun standalone, both provide completely different results. One starts a Cmder/Clink enhanced shell in the current shell session the other launches Conemu and starts a completely new shell session in the Conemu window.

I have said before I am concerned with adding so much functionality to the launcher that it becomes difficult to maintain.

I am also concerned about breaking existing functionality.

Currently cmder.exe accepts a start directory in the following ways:

cmder /start c:\start_in_this_dir

or

cmder c:\start_in_this_dir

We can't just throw a random arg at it because it errors on unknown/invalid command line args.

If this functionality is added it would need to be in a way that used a prefix like /uflags "/noautorun /dosomething /dosomethingelse". The value of /uflags could then be set to %CMDER_USER_FLAGS%.

To me the meat of this PR is the library that makes it easy for easy determination of whether a flag was passed or not. Currently the lib does not appear to adhere to the format of our other libraries in %cmder_root%\vendor\lib so that is an issue I have.

I need to look closer though and do a full test and review of the PR, if I am misunderstanding something please clarify.

[xiazeyu]

@daxgames I think your understanding is exactly the same with me.

About pass args to init.bat or launcher:

• If the flags are not passed from the launcher (Cmder.exe), I'll write the required code to make it happen. I think it will be useful to have both launcher and init.bat able to set flags.

#1758 (comment)
This has nothing to do with the original design. It depends on you if you will add the function of passing args by launcher. Since this is beyond by ability, if you think it too risky to add such function to launcher, just ignore the idea or mark it as a new feature and solve it in a later PR.

About format:

I think some of the difference exists because scripts in %cmder_root%\vendor\lib are mostly designed for init.bat, and not for the user. So it won't handling with args like "/h" and wrong syntax.

If you stick to it, you need to unite the format by yourself(sorry about that), since I can't get the rule of format(stylistic issues, comments style, best process flow as a lib).(It's think this solving this issue is not like using ESLint, which has a fixed rules to follow).

Thanks for your review and test anyway.

[daxgames]

I have adapted it to a cmder library and can PR back to @xiazeyu.

[daxgames]

I changed my mind I did not make it a library.

In my opinion flag_exists.cmd does not adequately describe what this does. It as actually a conditional execution based on a detected/undetected flag passed to init.bat.

In my PR to @xiazeyu I have:

• Renamed %cmder_root%/vendor/lib/flag_exists.cmd to %cmder_root%/vendor/bin/cexec.cmd
  • This makes the file easily callable by its name since %cmder_root%/vendor/bin/ is added to the path
• Modified the cexec /setpath to set:
  • ccall=call C:\Users\user\cmderdev\vendor\bin\cexec.cmd Evaluates flags, runs commands if found, and returns to the calling script and continues.
    • Example: %ccall% /startnotepad start notepad.exe
  • cexec=C:\Users\user\cmderdev\vendor\bin\cexec.cmd Evaluates flags, runs commands if found, and does not return to the calling script.
    • Example: %cexec% /startnotepad start notepad.exe
• Added exit codes to allow multi conditional execution:
  • If a flag is detected and the command is run cexec exists with an %ERRORLEVEL%=0
  • If not is specified and a flag is not detected and the command is run cexec exists with an %ERRORLEVEL%=0
  • Else cexec exists with %ERRORLEVEL%=1
  • Example: %ccall% "/startNotepad" "start" "notepad.exe" && %call% not "/startwordpad" "start" "wordpad.exe"
    • Wordpad is only started if %CMDER_USER_FLAGS% contains both /startNotepad and /startwordpad
• Updated the documentation in the readme.md.

[DRSDavidSoft]

@daxgames

Regarding the launcher arguments

To be clear, I didn't plan to throwing random arguments from the launcher to init.bat! I was certainly thinking of the prefixing idea, but TBH I was planning on calling it /initflags, but I like your /uflags idea better.

On the note that is it necessary or not, I would imagine as the launcher, it should be possible to pass any init.bat arguments using the launcher. The only argument is on how to do it. If you agree on prefixing it, I'd like to ask permission to add it to the launcher.

Regarding the format

I had planned on refactoring @xiazeyu's batch file to match the other libs (like you initially did), but considering the format and the nature of the file, I also agree with separating it from the other libs.

May I ask why cexec.cmd? What does that stand for?
EDIT: Conditional Execution, found it.

Regarding maintainability

I made a note at the end of #1873 (comment)

---

@xiazeyu

I noticed that @daxgames has already made some of the necessary changes in his PR, here: https://github.com/xiazeyu/cmder/pull/1.
There are still a couple of minor issues regarding the formatting that I have in mind; I will commit them and make a separate PR in your branch after you merge @daxgames's PR.

[daxgames]

I see found what cexec was. I just think it is much more accurate than flag_exists. I would expect flag_exists to simply return a binary yes or no but it does much more than that.

The only way I can see the launcher passing flags to init.bat is trough an environment variable like %CMDER_ARGS%. The variable could then be added to the default cmder tasks in conemu.

[daxgames]

The only issue with the above approach is it is a manual change to the cmder task config for existing users that already have a user-conemu.xml file.

Just spit balling here but we could instead add some code to init.bat to append %* to %CMDER_ARGS% then have the command line parser parse %CMDER_ARGS% instead of %* then it would not have to be added the the cmder task in conemu.

[xiazeyu]

Renamed %cmder_root%/vendor/lib/flag_exists.cmd to %cmder_root%/vendor/bin/cexec.cmd

• This makes the file easily callable by its name since %cmder_root%/vendor/bin/ is added to the path

Does it mean that you can use cexec /startnotepad start notepad.exe instead of %cexec% /startnotepad start notepad.exe? Since this vendor/bin didn't occur in the current release, I'm not sure about this.
Anyway, Is it a conflict or you wants to preserve both calling method for compatibility?

If cexec, I think it's better to create another script called ccall and remove the /setPath detection.

[daxgames]

LGTM 👍 👍