Menu ▾ ▴

#1902 Add ability to execute .bat files from an MSYS shell

MSYS
open
Cesar Strauss
None
Feature
none
Unknown
False
2014-08-23
2011-06-06
Fabian Greffrath
No

According to its wiki page, MSYS "is intended to supplement MinGW and the deficiencies of the cmd shell." While this is mostly true and appreciated, there is one specific detail in which the MSYS shell fails for me: I cannot execute batch files from it. The most prominent example that bugs me is that I cannot evoke an MSYS build environment via "/c/mingw/msys/1.0/msys.bat MSYS" from a standard MinGW shell - but my concern is not limited to this example.

Do you think it is somehow possible (and reasonable) to extend MSYS to make it able to execute batch files? I am not thinking about directly parsing, but about detecting them and then executing them via e.g. "cmd.exe /C example.bat" - imagine something similar to Linux's binfmt mechanism. Furthermore, batch files (i.e. .bat and .cmd extensions) should appear in bash's tab completion and the output of which(1) alongside normal .exe files.

I am however not sure about the availability of variables that are set in such a batch file. Are there any other obvious deficiencies that I am missing here?

Discussion

  • Keith Marshall

    Keith Marshall - 2011-06-06

    Not a bug report -- reassigning as feature request.

     

  • Keith Marshall

    Keith Marshall - 2011-06-06
    • labels: 380073 --> MSYS
     

  • Hans Fr. Nordhaug

    Hans Fr. Nordhaug - 2012-12-06

    This would be a really nice feature to have. Any hope of seeing this happen?

     

  • Earnie Boyd

    Earnie Boyd - 2013-02-15

    Ticket moved from /p/mingw/feature-requests/91/

     

  • Earnie Boyd

    Earnie Boyd - 2013-02-15

    And can't we do that now?

    cmd.exe //c foo.bat
    start foo.bat

    #!/bin/sh
#This is a shell script named /bin/foo
start /path/to/foo.bat

    Then just execute /bin/foo to start it?

     

    Last edit: Earnie Boyd 2013-02-15

  • Earnie Boyd

    Earnie Boyd - 2013-02-15
    • labels: MSYS -->
    • assigned_to: Cesar Strauss
    • milestone: --> MSYS
    • type: --> Feature
    • resolution: --> none
    • category: --> Unknown
    • patch_attached: --> False
     

  • Sebastian Schuberth

    Sebastian Schuberth - 2013-02-17

    The problem with the cmd.exe / start / wrapper script approaches is that those won't work as expected if you have a .bat / .cmd file in your PATH and assume it to be executed when you type its name on the shell (with or without the .bat / .cmd extension).

     

    • Keith Marshall

      Keith Marshall - 2013-02-17

      This is not true. This trivial example

      $ echo '@echo hello from foobat!' > /bin/foobat.bat

$ cmd //c foobat
hello from foobat!

      shows the equivalent of a "cmd //c" wrapper invoking a .bat file, located via a $PATH search. Extend that, to create the actual wrapper script

      $ echo '#!/bin/sh
> cmd //c "$0" "$@"' > /bin/foobat

$ foobat
hello from foobat!

      and your assertion is disproved.

       

  • Sebastian Schuberth

    Sebastian Schuberth - 2013-02-17

    I probably should have added that by "work as expected" I mean that we won't need one wrapper script per batch file that we'd like to execute.

     

    • Keith Marshall

      Keith Marshall - 2013-02-17

      On NTFS, one generic wrapper (as in my example) is sufficient, but I do take your point that one directory link (hardlink) to that, per batch file is required. Mitigating this: in MSYS sh you have a much richer scripting language than cmd.exe provides, so you are probably better off writing Bourne shell scripts in the first place.

      Certainly, it should be possible to adapt MSYS bash to spawn a cmd.exe process to run a batch file. However, that requires developer effort, to add the necessary support, (and to maintain a local patch in perpetuity, because I don't expect Chet Ramey to be particularly interested in the burden of maintaining support for such a capability in upstream bash sources), and I don't see a rush of volunteers stepping forward to commit to that effort. Ultimately, the decision to add such support will lie with Cesar Strauss, (the MSYS maintainer), so there is a demand on his time, in addition to that of any other developer providing the patch, (even if one does feel the incentive, which I certainly don't).

      OTOH, the wrapper script technique is available to you right now.

       

  • mcandre

    mcandre - 2013-02-17

    Please add this feature! Many programs are distributed as .bat files, it sucks to have to alternate between Command Prompt and MSYS based on the kind of program you want to run.

     

    • Keith Marshall

      Keith Marshall - 2013-02-19

      it sucks to have to alternate between Command Prompt and MSYS based on the kind of program you want to run.

      And both Earnie and I have already shown you that you don't need to; when the command you want to run is a cmd.exe script, you can run it directly from MSYS, as:

      cmd //c script to be run

      I'm still seeing only "you guys should do this" attitude, and not a sign of any of the "let me see if I can help with this" open source driving force.

       

  • Sebastian Schuberth

    Sebastian Schuberth - 2013-02-19

    For anyone interested, I have prototyped a possible solution which neither requires an explicit "cmd //c" or "start" prefix nor any wrapper script / link per batch file. The idea is to emulate ZSH's preexec functionality and use that to automatically prefix the command with "cmd //c" in case of a .bat or .cmd file. For the details see (currently starting at commit a80a52f):

    https://github.com/sschuberth/mingwGitDevEnv/commits/preexec-batch-files

     

    • Earnie Boyd

      Earnie Boyd - 2013-02-19

      Please attach a patch here based on the msys runtime repository code. I'm not about to go chasing a patch against a disparate fork.

       

  • mcandre

    mcandre - 2013-02-19

    Okay, so .bat's are accessible within MSYS as "cmd prog.bat". But this
    breaks all kinds of scripts that call "prog" directly. Don't expect
    hundreds of software developers out there to rewrite all their
    Windows-centric scripts in mind with MSYS.

    Bottom line: We could make a lot of people happier if we just added ".bat"
    searching along with ".exe" searching to MSYS.

    On Mon, Feb 18, 2013 at 10:03 PM, Keith Marshall <keithmarshall@users.sf.net

    wrote:

    it sucks to have to alternate between Command Prompt and MSYS based on the
    kind of program you want to run.

    And both Earnie and I have already shown you that you don't need to;
    when the command you want to run is a cmd.exe script, you can run it directly
    from MSYS    , as:

    cmd //c script to be run

    I'm still seeing only "you guys should do this" attitude, and not a sign
    of any of the "let me see if I can help with this" open source driving
    force.

    • [bugs:#1902] Add ability to execute .bat files from an MSYS shell*

    Status: open
    Created: Mon Jun 06, 2011 12:09 PM UTC by Fabian Greffrath
    Last Updated: Sun Feb 17, 2013 11:01 PM UTC
    Owner: Cesar Strauss

    According to its wiki page, MSYS "is intended to supplement MinGW and the
    deficiencies of the cmd shell." While this is mostly true and appreciated,
    there is one specific detail in which the MSYS shell fails for me: I cannot
    execute batch files from it. The most prominent example that bugs me is
    that I cannot evoke an MSYS build environment via
    "/c/mingw/msys/1.0/msys.bat MSYS" from a standard MinGW shell - but my
    concern is not limited to this example.

    Do you think it is somehow possible (and reasonable) to extend MSYS to
    make it able to execute batch files? I am not thinking about directly
    parsing, but about detecting them and then executing them via e.g. "cmd.exe
    /C example.bat" - imagine something similar to Linux's binfmt mechanism.
    Furthermore, batch files (i.e. .bat and .cmd extensions) should appear in
    bash's tab completion and the output of which(1) alongside normal .exe
    files.

    I am however not sure about the availability of variables that are set in
    such a batch file. Are there any other obvious deficiencies that I am
    missing here?

    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/mingw/bugs/1902/

    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/prefs/

    --
    Cheers,

    Andrew Pennebaker
    www.yellosoft.us

     

    • Keith Marshall

      Keith Marshall - 2013-02-19

      Okay, so .bat's are accessible within MSYS as "cmd prog.bat". But this
      breaks all kinds of scripts that call "prog" directly. Don't expect
      hundreds of software developers out there to rewrite all their
      Windows-centric scripts in mind with MSYS.

      Really? Exactly how many hundreds of software developers are stupid enough to write Bourne shell scripts which expect to be able to invoke *.bat scripts without prefixing the command with "cmd //c"? Sure, they might write *.cmd or *.bat scripts which call other such scripts, but that doesn't matter; once the top level script has been invoked as a "cmd //c" subprocess, all processing within it is handled by cmd.exe.

      Sorry, but you seem to be making a bogus case for the usefulness of such a feature. Your arguments are not impressing me.

       

  • mcandre

    mcandre - 2013-02-19

    "cmd" may handle all further calls to a .bat file, but what about when the
    .bat file makes calls that depend on mingw tools such as "rm", "ls", and
    .sh scripts?

    Intermixing is common and we should probably handle .bat's just as we
    handle .exe's.

    On Tue, Feb 19, 2013 at 11:07 AM, Keith Marshall <keithmarshall@users.sf.net

    wrote:

    Okay, so .bat's are accessible within MSYS as "cmd prog.bat". But this
    breaks all kinds of scripts that call "prog" directly. Don't expect
    hundreds of software developers out there to rewrite all their
    Windows-centric scripts in mind with MSYS.

    Really? Exactly how many hundreds of software developers are stupid
    enough to write Bourne shell scripts which expect to be able to invoke
    .bat scripts without prefixing the command with "cmd //c"? Sure, they
    might write     .cmd or *.bat scripts which call other such scripts, but that
    doesn't matter; once the top level script has been invoked as a "cmd //c"
    subprocess, all processing within it is handled by cmd.exe.

    Sorry, but you seem to be making a bogus case for the usefulness of such a
    feature. Your arguments are not impressing me.

    • [bugs:#1902] Add ability to execute .bat files from an MSYS shell*

    Status: open
    Created: Mon Jun 06, 2011 12:09 PM UTC by Fabian Greffrath
    Last Updated: Tue Feb 19, 2013 10:09 AM UTC
    Owner: Cesar Strauss

    According to its wiki page, MSYS "is intended to supplement MinGW and the
    deficiencies of the cmd shell." While this is mostly true and appreciated,
    there is one specific detail in which the MSYS shell fails for me: I cannot
    execute batch files from it. The most prominent example that bugs me is
    that I cannot evoke an MSYS build environment via
    "/c/mingw/msys/1.0/msys.bat MSYS" from a standard MinGW shell - but my
    concern is not limited to this example.

    Do you think it is somehow possible (and reasonable) to extend MSYS to
    make it able to execute batch files? I am not thinking about directly
    parsing, but about detecting them and then executing them via e.g. "cmd.exe
    /C example.bat" - imagine something similar to Linux's binfmt mechanism.
    Furthermore, batch files (i.e. .bat and .cmd extensions) should appear in
    bash's tab completion and the output of which(1) alongside normal .exe
    files.

    I am however not sure about the availability of variables that are set in
    such a batch file. Are there any other obvious deficiencies that I am
    missing here?

    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/mingw/bugs/1902/

    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/prefs/

    --
    Cheers,

    Andrew Pennebaker
    www.yellosoft.us

     

    • Earnie Boyd

      Earnie Boyd - 2013-02-19

      That is not a supported feature.

       

      • Earnie Boyd

        Earnie Boyd - 2013-02-19

        That doesn't mean we will not entertain a patch for considering a batch file as a non-MSYS executable.

         

  • mcandre

    mcandre - 2013-02-19

    Understood.

    I've begun searching the mingw code for where it searches for .exe programs
    on invokation. Maybe related to shellapi?

    http://sourceforge.net/p/mingw/mingw-org-wsl/ci/21762bb4a1bd0c88c38eead03f59e8d994349e83/tree/include/shellapi.h#l346

    On Tue, Feb 19, 2013 at 12:32 PM, Earnie Boyd earnie@users.sf.net wrote:

    That doesn't mean we will not entertain a patch for considering a batch
    file as a non-MSYS executable.

    • [bugs:#1902] Add ability to execute .bat files from an MSYS shell*

    Status: open
    Created: Mon Jun 06, 2011 12:09 PM UTC by Fabian Greffrath
    Last Updated: Tue Feb 19, 2013 10:09 AM UTC
    Owner: Cesar Strauss

    According to its wiki page, MSYS "is intended to supplement MinGW and the
    deficiencies of the cmd shell." While this is mostly true and appreciated,
    there is one specific detail in which the MSYS shell fails for me: I cannot
    execute batch files from it. The most prominent example that bugs me is
    that I cannot evoke an MSYS build environment via
    "/c/mingw/msys/1.0/msys.bat MSYS" from a standard MinGW shell - but my
    concern is not limited to this example.

    Do you think it is somehow possible (and reasonable) to extend MSYS to
    make it able to execute batch files? I am not thinking about directly
    parsing, but about detecting them and then executing them via e.g. "cmd.exe
    /C example.bat" - imagine something similar to Linux's binfmt mechanism.
    Furthermore, batch files (i.e. .bat and .cmd extensions) should appear in
    bash's tab completion and the output of which(1) alongside normal .exe
    files.

    I am however not sure about the availability of variables that are set in
    such a batch file. Are there any other obvious deficiencies that I am
    missing here?

    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/mingw/bugs/1902/

    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/prefs/

    --
    Cheers,

    Andrew Pennebaker
    www.yellosoft.us