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

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

@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?

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

@daxgames ready to merge or nah?

P.S. 1

@daxgames I can write alib_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 yourvsCode.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

@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?

@daxgames Sure. I propose adding asimple wrapper to be used as argument handler, instead offind /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 /bREM this section should be called from either `init.bat` or `user-profile.bat`call :conditionalCall switchname1 exampleFunctioncall :conditionalCall switchname2 anotherFunctionREM 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 inuser-profile.bat

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

@DRSDavidSoft

I think document this function inREADME.md is a good idea.

In myvsCode.cmd, there's nothing but acall %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 myvsCode.cmd for. TypevsCode, and I can shell vs cofe, and not interrupt my current console job.

I think your wapper idea is excellent, that will makeuser-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 ifuder-profile.cmd has too much, and add more file may make it bloated.

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

@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! :)

@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.

@xiazeyu Cmder has a concept of importable libraries invendor\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 invendor\lib as examples.

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

I am not sure I likehave as themethod name, I am thinkingflag_exists as the method that checks if a flag is set andflag_exists not could check for the absence of the flag.

Thoughts?

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

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

@daxgames, thoughts?

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

Thanks for the contribution, btw!

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

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.

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

@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 andinit.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 inuser-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.

I passed toinit.bat because I need to use itwith no launcher in vsCode.
things likecmder.exe /cpp orcmder.exe /nodejs orcmder.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.

@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 frombothinit.bat andCmder.exe to make it unified? Personally I only useinit.bat, but that's for power users like you and me. The regular users will stick toCmder.exe and I think adding your featurealso to the main launcher will greatly benefit them.

Also,@daxgames, your thoughts please.

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

@DRSDavidSoft and@xiazeyu I am not sure we need to add this functionality tocmder.exe, I am not sure I understand why its needed. The stated use case is to runinit.bat /noautorun in a shell from another tool not runningcmder.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.

Currentlycmder.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.

@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 andinit.bat able to set flags.

#1758 (comment)
This has nothing to do with the original design. Itdepends on you if you willadd the function of passing args by launcher. Since this is beyond by ability, if you think it too risky toadd 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 forinit.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.

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

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

In my opinionflag_exists.cmd does not adequately describe what this does. It as actually a conditional execution based on a detected/undetected flag passed toinit.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 thecexec /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 runcexec exists with an%ERRORLEVEL%=0
  • Ifnot is specified and a flag is not detected and the command is runcexec exists with an%ERRORLEVEL%=0
  • Elsecexec 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 thereadme.md.

@daxgames

Regarding the launcher arguments

To be clear, I didn't plan to throwing random arguments from the launcher toinit.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 anyinit.bat arguments using the launcher. The only argument is onhow 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 whycexec.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 ofminor 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.

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.

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

Just spit balling here but we could instead add some code toinit.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.

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 usecexec /startnotepad start notepad.exe instead of%cexec% /startnotepad start notepad.exe? Since thisvendor/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?

Ifcexec, I think it's better to create another script calledccall and remove the/setPath detection.