Menu
▾
▴
mingw-users
|
From: Yuri K. <yur...@gm...> - 2014-06-24 22:11:34
|
If I understand you correctly, using single quotes is no better than using double quotes here. Both commands: $ cmd //c '"cmd" /c echo test' $ cmd //c "\"cmd\" /c echo test" produce the same command line: c:\Windows\system32\cmd.exe /c "\"cmd\" /c echo test" And they doesn't do what they are supposed to do. The point here is to pass the following command line to the process: c:\Windows\system32\cmd.exe /c ""cmd" /c echo test" AFAIR, some programs, amongst which are cmd, start, hstart, treat their command line specially. When given things like `""cmd" /c echo test"`, they just ignore the outer quotes or treat the whole thing as one big quoted argument. So, is there a way to make it so that GetCommandLine() would return exactly this: e:\showargv.exe ""c:\Program Files\foo" /k echo foo" ? > MSYS sh DTRT here,automatically inserting double quotes where needed, to keep arguments with embedded white space, or embedded special characters, intact. To be honest, it looks like MSYS sh has too much magic in it. Generally, I prefer straightforward behavior and don't like when programs make up my mind for me. Because it usually makes things more complex than they should be. But I don't know the reasoning, so I might be evidently wrong here. Regards, Yuri |
|
From: Yuri K. <yur...@gm...> - 2014-06-26 07:09:26
|
>
> If it a script written for Linux, then why do you invoke cmd.exe from
> MSYS Bash?
I need to restart nginx, cmd.exe was there for example. My concern is
running hstart, I was talking about. It allows to run programs with
elevated privileges. So, in truth I'm aiming to do something along the
lines:
hstart //elevate ""$NGINX_PATH" -s reload ${NGINX_CONF_PATH:+-c
"$NGINX_CONF_PATH"}"
hstart also has cmd-like syntax.
Why that colleague of yours cannot invoke the (converted)
> script from cmd.exe?
>
I don't like the idea of supporting both bash and non-bash versions.
Regards,
Yuri
|
|
From: Jim M. <jmi...@ya...> - 2014-06-24 22:49:32
|
windows uses ^ for most chars escape not \ but there is no escape for " and % for % this is a specification problem. complain to microsoft about it. >________________________________ > From: Yuri Kanivetsky <yur...@gm...> >To: min...@li... >Sent: Tuesday, June 24, 2014 3:11 PM >Subject: Re: [Mingw-users] running programs from MSYS with quotes > > > >If I understand you correctly, using single quotes is no better than using double quotes here. Both commands: > > >$ cmd //c '"cmd" /c echo test' > >$ cmd //c "\"cmd\" /c echo test" > > > >produce the same command line: > > >c:\Windows\system32\cmd.exe /c "\"cmd\" /c echo test" > > > >And they doesn't do what they are supposed to do. The point here is to pass the following command line to the process: > > >c:\Windows\system32\cmd.exe /c ""cmd" /c echo test" > > >AFAIR, some programs, amongst which are cmd, start, hstart, treat their command line specially. When given things like `""cmd" /c echo test"`, they just ignore the outer quotes or treat the whole thing as one big quoted argument. So, is there a way to make it so that GetCommandLine() would return exactly this: e:\showargv.exe ""c:\Program Files\foo" /k echo foo" ? > > >> MSYS sh DTRT here,automatically inserting double quotes where needed, to keep arguments with embedded white space, or embedded special characters, intact. > > >To be honest, it looks like MSYS sh has too much magic in it. Generally, I prefer straightforward behavior and don't like when programs make up my mind for me. Because it usually makes things more complex than they should be. But I don't know the reasoning, so I might be evidently wrong here. > > >Regards, >Yuri >------------------------------------------------------------------------------ >Open source business process management suite built on Java and Eclipse >Turn processes into business applications with Bonita BPM Community Edition >Quickly connect people, data, and systems into organized workflows >Winner of BOSSIE, CODIE, OW2 and Gartner awards >http://p.sf.net/sfu/Bonitasoft >_______________________________________________ >MinGW-users mailing list >Min...@li... > >This list observes the Etiquette found at >http://www.mingw.org/Mailing_Lists. >We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > >_______________________________________________ >You may change your MinGW Account Options or unsubscribe at: >https://lists.sourceforge.net/lists/listinfo/mingw-users >Also: mailto:min...@li...?subject=unsubscribe > > |
|
From: Keith M. <kei...@us...> - 2014-06-25 00:06:04
|
On 24/06/14 23:11, Yuri Kanivetsky wrote: > If I understand you correctly, using single quotes is no better than using > double quotes here. Both commands: > > $ cmd //c '"cmd" /c echo test' > $ cmd //c "\"cmd\" /c echo test" > > produce the same command line: > > c:\Windows\system32\cmd.exe /c "\"cmd\" /c echo test" Correct. The inner pair of double quotes are literal; according to both http://msdn.microsoft.com/en-us/library/a1y7w461.aspx and http://msdn.microsoft.com/en-us/library/17w5ykft.aspx when embedded within outer double quotes, (as Windows requires, because it doesn't attribute any significance to single quotes), these inner quotes must be escaped, to have them parsed as such. > And they doesn't do what they are supposed to do. The point here is to pass > the following command line to the process: > > c:\Windows\system32\cmd.exe /c ""cmd" /c echo test" Well, applying the parsing logic from each of those MSDN references, that is identically equivalent to c:\Windows\system32\cmd.exe /c cmd" /c echo test" because the first pair of quotes delimit an empty string. > AFAIR, some programs, amongst which are cmd, start, hstart, treat their > command line specially. When given things like `""cmd" /c echo test"`, they > just ignore the outer quotes or treat the whole thing as one big quoted > argument. Then such programs violate Microsoft's own parsing conventions, insofar as they apply to applications using their own C/C++ runtime. MSYS has been developed to interoperate with applications which do conform to those conventions, and accordingly DTRT. > So, is there a way to make it so that GetCommandLine() would > return exactly this: e:\showargv.exe ""c:\Program Files\foo" /k echo foo" ? That is doubtful, since the proper (conforming) intent would have been e:\showargv.exe "c:\Program Files\foo" /k echo foo or maybe e:\showargv.exe "c:\Program Files\foo" /k "echo foo" If you want to invoke arcane applications, with anomalous command line parsing conventions, then you may need a wrapper program, to parse the literal command line, interpreting the escapes according to the C/C++ runtime conventions, whence reconstructing the anomalously intended argument string, which it then forwards to CreateProcess(). Sometimes, you need to think outside the box. It could be that such a forwarding wrapper would be a useful addition to MSYS itself; perhaps Cesar, (the MSYS maintainer), could comment? -- Regards, Keith. |
|
From: Eli Z. <el...@gn...> - 2014-06-25 13:51:26
|
> Date: Wed, 25 Jun 2014 01:05:55 +0100 > From: Keith Marshall <kei...@us...> > > On 24/06/14 23:11, Yuri Kanivetsky wrote: > > If I understand you correctly, using single quotes is no better than using > > double quotes here. Both commands: > > > > $ cmd //c '"cmd" /c echo test' > > $ cmd //c "\"cmd\" /c echo test" > > > > produce the same command line: > > > > c:\Windows\system32\cmd.exe /c "\"cmd\" /c echo test" > > Correct. The inner pair of double quotes are literal; according to both > http://msdn.microsoft.com/en-us/library/a1y7w461.aspx and > http://msdn.microsoft.com/en-us/library/17w5ykft.aspx Those URLs describe what the standard C/C++ library startup code does to convert the command line into the argv[] array. But a program doesn't have to use that startup code, it can provide its own (and in fact, MinGW 4.x actually does). It can even (gasp!) not be a C/C++ program. IOW, these are in no way Windows-wide requirements, they are limited to programs that use standard C/C++ libraries for their startup code. In particular, those URLs are not applicable to how cmd.exe treats quoted command arguments. > > And they doesn't do what they are supposed to do. The point here is to pass > > the following command line to the process: > > > > c:\Windows\system32\cmd.exe /c ""cmd" /c echo test" > > Well, applying the parsing logic from each of those MSDN references, > that is identically equivalent to > > c:\Windows\system32\cmd.exe /c cmd" /c echo test" > > because the first pair of quotes delimit an empty string. That's not how cmd.exe handles that command line. The definition of how cmd.exe does that is part of what "cmd /?" displays; here's the relevant part: If /C or /K is specified, then the remainder of the command line after the switch is processed as a command line, where the following logic is used to process quote (") characters: 1. If all of the following conditions are met, then quote characters on the command line are preserved: - no /S switch - exactly two quote characters - no special characters between the two quote characters, where special is one of: &<>()@^| - there are one or more whitespace characters between the the two quote characters - the string between the two quote characters is the name of an executable file. 2. Otherwise, old behavior is to see if the first character is a quote character and if so, strip the leading character and remove the last quote character on the command line, preserving any text after the last quote character. Item 1 is lawyer-speak, but if you read it carefully several time, you will understand that it almost never happens. It is only here for the special case that the program you invoke has whitespace in its file name. So the interesting part is item 2, which describes "old behavior" (a hint to why cmd.exe does what it does), and it boils down to a very simple rule of quoting command lines to be passed to cmd.exe: compose a command line you would type at the shell prompt, with quotes wherever you need them, then simply enclose the whole command-line string in an extra pair of quotes. That's it! IOW, the OP is correct: MSYS ought to have special support for invoking cmd.exe by either automatically enclosing cmd.exe commands in quotes, or at least allowing users some fire escape whereby they could achieve that effect. > > AFAIR, some programs, amongst which are cmd, start, hstart, treat their > > command line specially. When given things like `""cmd" /c echo test"`, they > > just ignore the outer quotes or treat the whole thing as one big quoted > > argument. > > Then such programs violate Microsoft's own parsing conventions No, they don't; see above. But even if they did, cmd.exe is not some obscure or "arcane" program. So it is IMO meaningless to claim that it violates some conventions; a program that invokes a stock Windows shell without honoring how that shell handles quoted commands is simply a broken program. You cannot have a useful Windows program that invokes other programs, if it doesn't know how to invoke cmd.exe correctly and reliably. > MSYS has been developed to interoperate with applications which do > conform to those conventions, and accordingly DTRT. This means, plain and simple, that MSYS is inappropriate for invoking cmd.exe. Which is not a catastrophe, at least not for people who, like me, limit MSYS usage to configuring and building Posix software, where cmd.exe does not need to be invoked. But other MinGW users, who do like using MSYS in routine operation of their Windows boxes, might not be pleased by this conclusion. It would be nice if MSYS developers added proper support for passing quoted commands to cmd.exe. |
|
From: Yuri K. <yur...@gm...> - 2014-06-25 23:30:22
|
> > 1. If all of the following conditions are met, then quote characters > on the command line are preserved: > > - no /S switch > - exactly two quote characters > - no special characters between the two quote characters, > where special is one of: &<>()@^| > - there are one or more whitespace characters between the > the two quote characters > - the string between the two quote characters is the name > of an executable file. > > Item 1 is lawyer-speak, but if you read it carefully several time... > Indeed a lawyer-speak. Finally I've managed to understand what it says :) > So the interesting part is item 2, which describes "old behavior" (a > hint to why cmd.exe does what it does)... > I thought it's item 1 that is an old behavior. This means, plain and simple, that MSYS is inappropriate for invoking > cmd.exe. Which is not a catastrophe, at least not for people who, > like me, limit MSYS usage to configuring and building Posix software, > where cmd.exe does not need to be invoked. But other MinGW users, who > do like using MSYS in routine operation of their Windows boxes, might > not be pleased by this conclusion. > Well, the script I need this thing for was originally written for linux, but now that I have a colleague working under windows, there arose the necessity of having it run under windows. As the script basically runs other programs and copies files I thought the bash was still a good fit for it. Not that I changed my mind yet. |
|
From: Keith M. <kei...@us...> - 2014-06-27 19:35:28
|
On 25/06/14 14:51, Eli Zaretskii wrote: >> Date: Wed, 25 Jun 2014 01:05:55 +0100 >> From: Keith Marshall >> >> On 24/06/14 23:11, Yuri Kanivetsky wrote: >>> If I understand you correctly, using single quotes is no better than using >>> double quotes here. Both commands: >>> >>> $ cmd //c '"cmd" /c echo test' >>> $ cmd //c "\"cmd\" /c echo test" >>> >>> produce the same command line: >>> >>> c:\Windows\system32\cmd.exe /c "\"cmd\" /c echo test" >> >> Correct. The inner pair of double quotes are literal; according to both >> http://msdn.microsoft.com/en-us/library/a1y7w461.aspx and >> http://msdn.microsoft.com/en-us/library/17w5ykft.aspx > > Those URLs describe what the standard C/C++ library startup code does > to convert the command line into the argv[] array. Sure. A perfectly reasonable expectation, for a system intended to support applications using precisely that framework. > But a program doesn't have to use that startup code, it can provide its own (and in > fact, MinGW 4.x actually does). Well, yes, this is true in its default configuration, which attempts to provide saner handling of wildcard globbing tokens -- in response to your own bug report, Eli, and faced with deliberatly broken globbing behaviour introduced by Microsoft, with the advent of Vista. However, aside from the improved globbing behaviour, this replacement startup code is careful to preserve the parsing effect of the original Microsoft _getmainargs() handler; this may be readily proven by compiling my earlier test program with the '-D CRT_GLOB_OPTIONS=0' flag, (which has the effect of disabling MinGW's alternative parser, and simply calling _getmainargs() in its stead); when compiled thus, the output from my examples remains *identically* the same. > It can even (gasp!) not be a C/C++ program. Sure. However ... > IOW, these are in no way Windows-wide requirements, they are limited > to programs that use standard C/C++ libraries for their startup code. ... to reiterate, I don;t consider this to be an unreasonable expectation, for a system designed to interoperate with MSVCRT.DLL, (which provides precisely this startup API). > In particular, those URLs are not applicable to how cmd.exe treats > quoted command arguments. > >>> And they doesn't do what they are supposed to do. The point here is to pass >>> the following command line to the process: >>> >>> c:\Windows\system32\cmd.exe /c ""cmd" /c echo test" >> >> Well, applying the parsing logic from each of those MSDN references, >> that is identically equivalent to >> >> c:\Windows\system32\cmd.exe /c cmd" /c echo test" >> >> because the first pair of quotes delimit an empty string. > > That's not how cmd.exe handles that command line. [... snip ...] > IOW, the OP is correct: MSYS ought to have special support for > invoking cmd.exe by either automatically enclosing cmd.exe commands in > quotes, or at least allowing users some fire escape whereby they could > achieve that effect. I don't disagree; that's why I suggested that the MSYS maintainer might consider providing a simple (generic) wrapper, which could hand off explicitly consistent command lines in accordance with cmd.exe's arcane quoting expectations -- and yes, even if you don't consider cmd.exe to be arcane, the quoting syntax under discussion certainly *is*, IMO. >>> AFAIR, some programs, amongst which are cmd, start, hstart, treat their >>> command line specially. When given things like `""cmd" /c echo test"`, they >>> just ignore the outer quotes or treat the whole thing as one big quoted >>> argument. >> >> Then such programs violate Microsoft's own parsing conventions > > No, they don't; see above. But even if they did, cmd.exe is not some > obscure or "arcane" program. You are, of course, fully entitled to that opinion; personally, I have always considered cmd.exe, (and command.com before it), to be arcanely dysfunctional and inadequate -- an opinion to which I am equally entitled, so please respect it. > You cannot have a useful Windows program that invokes other programs, > if it doesn't know how to invoke cmd.exe correctly and reliably. Why? We are taking about a *shell* here -- a program which *replaces* cmd.exe, with (IMO) a much saner alternative. I've used it as such, *exclusively*, for years, and I have never felt in the slightest way disadvantaged that it may not "know how to invoke cmd.exe correctly and reliably"; I have never found cmd.exe to be even remotely useful. >> MSYS has been developed to interoperate with applications which do >> conform to those conventions, and accordingly DTRT. > > This means, plain and simple, that MSYS is inappropriate for invoking > cmd.exe. Which is not a catastrophe, at least not for people who, > like me, limit MSYS usage to configuring and building Posix software, > where cmd.exe does not need to be invoked. But other MinGW users, who > do like using MSYS in routine operation of their Windows boxes, might > not be pleased by this conclusion. See above. I've used MSYS precisely for "routine operation of my Windows box" for years, without ever experiencing the slightest hitch. (Yes, I know there may be some esoteric corner cases, which it doesn't handle well, and perhaps I've been lucky that they haven't affected me; there have also been some bugs which have been fixed along the way). > It would be nice if MSYS developers added proper support for passing > quoted commands to cmd.exe. It could be handled via a wrapper, as I've suggested; however, unless someone can propose a deterministic implementation, I definitely will not advocate any deeper, probably heuristic, and therefore broken by design, mechanism for achieving this. -- Regards, Keith. |
|
From: Eli Z. <el...@gn...> - 2014-06-27 20:30:06
|
> Date: Fri, 27 Jun 2014 20:35:10 +0100 > From: Keith Marshall <kei...@us...> > > >> http://msdn.microsoft.com/en-us/library/a1y7w461.aspx and > >> http://msdn.microsoft.com/en-us/library/17w5ykft.aspx > > > > Those URLs describe what the standard C/C++ library startup code does > > to convert the command line into the argv[] array. > > Sure. A perfectly reasonable expectation, for a system intended to > support applications using precisely that framework. The system supports more than that single framework. In fact, Windows's native behavior is limited to command line as a single string; that's why the most primitive API, CreateProcess, accepts command arguments in that form, and in that form only. Breaking it into argv[] is a bow towards C standards, which explicitly require that. > > IOW, these are in no way Windows-wide requirements, they are limited > > to programs that use standard C/C++ libraries for their startup code. > > ... to reiterate, I don;t consider this to be an unreasonable > expectation, for a system designed to interoperate with MSVCRT.DLL, > (which provides precisely this startup API). MSVCRT.DLL is an implementation of the standard C library. Non-C programs don't need to be compatible with it. > >> Then such programs violate Microsoft's own parsing conventions > > > > No, they don't; see above. But even if they did, cmd.exe is not some > > obscure or "arcane" program. > > You are, of course, fully entitled to that opinion; personally, I have > always considered cmd.exe, (and command.com before it), to be arcanely > dysfunctional and inadequate -- an opinion to which I am equally > entitled, so please respect it. We can agree to consider cmd.exe to be dysfunctional, but we cannot ignore it on that ground. > > You cannot have a useful Windows program that invokes other programs, > > if it doesn't know how to invoke cmd.exe correctly and reliably. > > Why? Because a Windows program that cannot invoke the standard Windows command shell correctly will be very limited in its usefulness. It cannot run batch files, for example, nor built-in cmd commands. > We are taking about a *shell* here -- a program which *replaces* > cmd.exe, with (IMO) a much saner alternative. I've used it as such, > *exclusively*, for years, and I have never felt in the slightest way > disadvantaged that it may not "know how to invoke cmd.exe correctly and > reliably"; I have never found cmd.exe to be even remotely useful. Sure, if you avoid cmd.exe, you trivially don't need to be able to invoke it. But then you are avoiding Windows in general, and that's not what we are talking about here. > > This means, plain and simple, that MSYS is inappropriate for invoking > > cmd.exe. Which is not a catastrophe, at least not for people who, > > like me, limit MSYS usage to configuring and building Posix software, > > where cmd.exe does not need to be invoked. But other MinGW users, who > > do like using MSYS in routine operation of their Windows boxes, might > > not be pleased by this conclusion. > > See above. I've used MSYS precisely for "routine operation of my > Windows box" for years, without ever experiencing the slightest hitch. I said "inappropriate for invoking cmd.exe". You did what you did without invoking cmd.exe, so how does that invalidate my claim? > > It would be nice if MSYS developers added proper support for passing > > quoted commands to cmd.exe. > > It could be handled via a wrapper, as I've suggested; however, unless > someone can propose a deterministic implementation, I definitely will > not advocate any deeper, probably heuristic, and therefore broken by > design, mechanism for achieving this. I already proposed a deterministic implementation. I will repeat it here: just wrap the entire cmd.exe command line in a pair of quotes, and otherwise leave the command line intact. This works; I implemented this in at least 2 widely used programs (with a 3rd to follow soon), and I have yet to see a single complaint. Note that this method of quoting will work only with cmd.exe; for other programs doing what MSYS does already is almost always TRT. So you need to have two methods: one for cmd.exe (and I'm told also 'start' and 'hstart'), the other for everything else. |
|
From: Keith M. <kei...@us...> - 2014-06-28 07:00:43
|
On 27/06/14 21:29, Eli Zaretskii wrote: >> Date: Fri, 27 Jun 2014 20:35:10 +0100 >> From: Keith Marshall >> >>>> http://msdn.microsoft.com/en-us/library/a1y7w461.aspx and >>>> http://msdn.microsoft.com/en-us/library/17w5ykft.aspx >>> >>> Those URLs describe what the standard C/C++ library startup code does >>> to convert the command line into the argv[] array. >> >> Sure. A perfectly reasonable expectation, for a system intended to >> support applications using precisely that framework. > > The system supports more than that single framework. Sigh! The system to which I was referring is MSYS; IT does NOT purport to support anything beyond this framework. I've better things to do with my time. EOD. -- Regards, Keith. |
|
From: Keith M. <kei...@us...> - 2014-06-28 15:51:48
Attachments:
passthru.c
|
On 28/06/14 08:00, Keith Marshall wrote: >> The system supports more than that single framework. > > Sigh! The system to which I was referring is MSYS; IT does NOT purport > to support anything beyond this framework. > > I've better things to do with my time. EOD. So, rather than waste any more time on futile debate of the Microsoft's lack of standardization for command line quoting conventions, I just went ahead and wrote the attached Q&D wrapper program. Applying it, in an MSYS shell session, to the OP's original example, I see: $ ./passthru 'cmd /c ""cmd" /c echo test"' test -- Regards, Keith. |
|
From: Yuri K. <yur...@gm...> - 2014-06-25 23:15:07
|
> > If you want to invoke arcane applications, with anomalous command line > parsing conventions, then you may need a wrapper program, to parse the > literal command line, interpreting the escapes according to the C/C++ > runtime conventions, whence reconstructing the anomalously intended > argument string, which it then forwards to CreateProcess(). > > Sometimes, you need to think outside the box. It could be that such a > forwarding wrapper would be a useful addition to MSYS itself; perhaps > Cesar, (the MSYS maintainer), could comment? > I suppose wrapper program would be overkill. At least for me. So I've come with a way to overcome this: $ echo 'cmd /c ""cmd" /k echo test"' | cmd Microsoft Windows [Version 6.2.9200] (c) 2012 Microsoft Corporation. All rights reserved. C:\Users\Yuri>cmd /c ""cmd" /k echo test" test C:\Users\Yuri> C:\Users\Yuri> Though, it spits some extra noise along the way. Also, since msys shell doesn't support process substitution, I was thinking about using mktemp, which produces strange output, as it appears. It made me stuck with this solution for now. And as I know see, msys has its own mktemp, which is not installed by default. Gotta give it a try. |
|
From: Eli Z. <el...@gn...> - 2014-06-25 13:55:09
|
> Date: Tue, 24 Jun 2014 15:49:24 -0700 > From: Jim Michaels <jmi...@ya...> > > windows uses ^ for most chars escape not \ but there is no escape for " and % for % this is a specification problem. complain to microsoft about it. Windows itself doesn't use anything for escaping special characters. The ^ escape character is a cmd.exe feature. The C/C++ startup code does not support it, and neither does CreateProcess. |
|
From: Eli Z. <el...@gn...> - 2014-06-26 02:56:20
|
> Date: Thu, 26 Jun 2014 02:15:01 +0300 > From: Yuri Kanivetsky <yur...@gm...> > > I suppose wrapper program would be overkill. At least for me. So I've come > with a way to overcome this: > > $ echo 'cmd /c ""cmd" /k echo test"' | cmd > Microsoft Windows [Version 6.2.9200] > (c) 2012 Microsoft Corporation. All rights reserved. > > C:\Users\Yuri>cmd /c ""cmd" /k echo test" > test > > C:\Users\Yuri> > C:\Users\Yuri> > > Though, it spits some extra noise along the way. Another, perhaps easier workaround is to write your command, as you'd type it at the cmd.exe prompt, to a batch file, and then invoke cmd.exe to run that batch file. If you keep the batch file's name without whitespace, the command that invokes it can side-step the quoting issue altogether. When you are done, delete the batch file. |
|
From: Eli Z. <el...@gn...> - 2014-06-26 02:58:41
|
> Date: Thu, 26 Jun 2014 02:30:15 +0300 > From: Yuri Kanivetsky <yur...@gm...> > > Well, the script I need this thing for was originally written for linux, > but now that I have a colleague working under windows, there arose the > necessity of having it run under windows. As the script basically runs > other programs and copies files I thought the bash was still a good fit for > it. Not that I changed my mind yet. If it a script written for Linux, then why do you invoke cmd.exe from MSYS Bash? Why that colleague of yours cannot invoke the (converted) script from cmd.exe? |
|
From: Yuri K. <yur...@gm...> - 2014-06-26 06:25:42
|
> > Another, perhaps easier workaround is to write your command, as you'd > type it at the cmd.exe prompt, to a batch file, and then invoke > cmd.exe to run that batch file. If you keep the batch file's name > without whitespace, the command that invokes it can side-step the > quoting issue altogether. It should work out even if it contains spaces, as long as I quote them. > When you are done, delete the batch file. It's not a script to be run once. It's to be executed from time to time. Additionally, before coming with pipe-to-cmd solution, I had other workaround in mind: >bash -l some\script.sh & hstart /elevate "cmd /k c:\path\to\nginx -s reload -c c:\path\to\nginx.conf" Come to think of it, I still use cmd.exe as you can see, so that the extra window wouldn't disappear right away and I could see the errors, if any. Regards, Yuri |
|
From: John B. <joh...@ho...> - 2014-06-26 09:05:25
|
On Thu, 26 Jun 2014 09:25:34 +0300 , Yuri Kanivetsky wrote: > >> Another, perhaps easier workaround is to write your command, as you'd >> type it at the cmd.exe prompt, to a batch file, and then invoke >> cmd.exe to run that batch file. If you keep the batch file's name >> without whitespace, the command that invokes it can side-step the >> quoting issue altogether. >> >> It should work out even if it contains spaces, as long as I quote them. >> >> When you are done, delete the batch file. > > It's not a script to be run once. It's to be executed from time to time. > Let your script generate the .cmd file when it runs: echo "myprog \"arg 1\" arg2"> test.cmd cmd /c test.cmd # will execute myprog "arg 1" arg2 rm test.cmd Regards, John Brown. |
|
From: Yuri K. <yur...@gm...> - 2014-06-26 11:18:17
|
>
> Let your script generate the .cmd file when it runs:
>
> echo "myprog \"arg 1\" arg2"> test.cmd
> cmd /c test.cmd # will execute myprog "arg 1" arg2
> rm test.cmd
>
That was one of the things I was talking earlier. But I wanted to use
mktemp for the purpose.
For now I'm using the following solution:
qNGINX_PATH=$(echo "$NGINX_PATH" | sed 's/"/\\"/g; s/\//\\/g')
qNGINX_CONF_PATH=$(echo "$NGINX_CONF_PATH" | sed 's/"/\\"/g; s/\//\\/g')
echo "hstart /elevate \"cmd /k \"\"$qNGINX_PATH\" ${NGINX_CONF_PATH:+-c
\"$qNGINX_CONF_PATH\"} -s reload\"\"" | cmd
I escape double quote symbols there, and convert slashes in paths, if user
were to specify linux style paths. Not a 100% solution. If somebody have
any suggestions I'm all ears.
Regards,
Yuri
|
|
From: John B. <joh...@ho...> - 2014-06-26 11:38:27
|
On Thu, 26 Jun 2014 14:18:10 +0300, Yuri Kanivetsky wrote: > I escape double quote symbols there, and convert slashes in paths, if > user were to specify linux style paths. Not a 100% solution. If > somebody have any suggestions I'm all ears. > > Regards, > Yuri > There is no need to convert slashes. Windows understands drive:/path/to/file. Regards, John Brown. |
|
From: Yuri K. <yur...@gm...> - 2014-06-27 11:35:22
|
> Let your script generate the .cmd file when it runs:
> echo "myprog \"arg 1\" arg2"> test.cmd
> cmd /c test.cmd # will execute myprog "arg 1" arg2
> rm test.cmd
That's slightly better than piping to cmd, but not as good as it could be.
With bash, it's generally better off passing arguments through command
line, rather then interpolating them into command to be executed (because
bash handles escaping by itself then):
a='some"string'
bash -c 'echo "'"$a"'"'
vs
a='some"string'
bash -c 'echo "$1"' -- "$a"
But since msys bash executes cmd and bat files by itself, this way is out
of the question:
tmp=`mktemp` && trap 'rm "$tmp" "$tmp.cmd"' EXIT
echo "hstart /elevate \"cmd /k \"\"%1\" ${NGINX_CONF_PATH:+-c \"%2\"}
-s reload\"\"" >"$tmp.cmd"
"$tmp.cmd" "$NGINX_PATH" ${NGINX_CONF_PATH:+"$NGINX_CONF_PATH"}
So the only advantage is that cmd doesn't pollute the output with
unnecessary noise:
qNGINX_PATH=$(echo "$NGINX_PATH" | sed -r 's/("|\\)/\\\1/g')
qNGINX_CONF_PATH=$(echo "$NGINX_CONF_PATH" | sed -r 's/("|\\)/\\\1/g')
tmp=`mktemp` && trap 'rm "$tmp" "$tmp.cmd"' EXIT
echo "@echo off & hstart /elevate \"cmd /k \"\"$qNGINX_PATH\"
${NGINX_CONF_PATH:+-c \"$qNGINX_CONF_PATH\"} -s reload\"\"" >"$tmp.cmd"
cmd /c "$(cd -- "$(dirname -- "$tmp")" && pwd -W)/$(basename --
"$tmp.cmd")"
Note, that I convert here path `/tmp/tmp....` to its windows form for cmd
to understand it.
And the solution without mktemp is as follows:
qNGINX_PATH=$(echo "$NGINX_PATH" | sed -r 's/("|\\)/\\\1/g')
qNGINX_CONF_PATH=$(echo "$NGINX_CONF_PATH" | sed -r 's/("|\\)/\\\1/g')
echo "hstart /elevate \"cmd /k \"\"$qNGINX_PATH\" ${NGINX_CONF_PATH:+-c
\"$qNGINX_CONF_PATH\"} -s reload\"\"" | cmd
As to interpolating variables into double quotes, quoting only " and \ must
be safe: http://x-yuri.tumblr.com/post/90048221548/cmd-quoting
Regards,
Yuri
|
|
From: Eli Z. <el...@gn...> - 2014-06-28 09:00:42
|
> Date: Sat, 28 Jun 2014 08:00:30 +0100 > From: Keith Marshall <kei...@us...> > > On 27/06/14 21:29, Eli Zaretskii wrote: > >> Date: Fri, 27 Jun 2014 20:35:10 +0100 > >> From: Keith Marshall > >> > >>>> http://msdn.microsoft.com/en-us/library/a1y7w461.aspx and > >>>> http://msdn.microsoft.com/en-us/library/17w5ykft.aspx > >>> > >>> Those URLs describe what the standard C/C++ library startup code does > >>> to convert the command line into the argv[] array. > >> > >> Sure. A perfectly reasonable expectation, for a system intended to > >> support applications using precisely that framework. > > > > The system supports more than that single framework. > > Sigh! The system to which I was referring is MSYS; IT does NOT purport > to support anything beyond this framework. OK, in that case, users should not expect MSYS to support invocation of cmd.exe commands. > I've better things to do with my time. So do I. |
