Re: latest cygwin: 'run' problem

[Achim Gratz]

Gary Johnson writes:
 After much fiddling (programming by successive approximation),

You should drop the cargo-cult programming before it hurts you.

 I came up with this:

 @START  C:\cygwin\bin\mintty.exe /bin/bash --login -c cd $(cygpath 
 -u $0); exec bash -i %~p1\

You want at least %~dp1 there (in an CMD window, type HELP CALL).  But
you can start mintty directly from the shortcut without any intervention
of START or run and you don't need a batch file or shell script either.
Things get a lot simpler if you cut out the intermediaries, although you
still need to be careful.  If you go through CMD or a shell script,
there are more levels of quoting involved and more processes to start.
Doing this through both a CMD and a shell script is seriously
overcomplicated and keeping track of what needs to go where is much more
difficult to figure out, so just don't do it.


 Using an explicit path to mintty lets me put the script itself
 someplace other than /bin.

 Because %~p1 ends with a backslash, I had to add another backslash
 before the closing quote to prevent the quote from being included in
 the path.  (See http://ss64.com/nt/syntax-args.html and
 http://ss64.com/nt/syntax-esc.html#escape.)

 I haven't tried it yet with a path that includes a space.  Tomorrow.

It won't work because you did not quote the result from cygpath.


If you want to get this right, you should work it out from the inside.
You want the cd command to get a directory name from a subcommand that
may contain spaces, so you need to quote the result:

cd $( ... )

Since the argument you're getting may actually be a filename, you need
to use the dirname command and quote its argument again:

cd $(/bin/dirname $(...))

and dirname gets its argument from cygpath, and the argument to cygpath
must itself be quoted again:

cd $($(/bin/dirname $(/bin/cygpath -u $1)))

If that suceeds you want to replace the current interpreter with an
interactive bash:

cd $($(/bin/dirname $(/bin/cygpath -u $1)))  exec /bin/bash -i

That is in entirety the command that you need to give to the -c option
of the outer bash invocation as a single argument.  The remaining
arguments are filled in from $0 and since I specified $1 to cygpath,
there's a dummy parameter to be placed, let's call it BashHere.  So
that outer bash needs to get started like this:

/bin/bash -lc cmd_argument BashHere dir_argument

Since you're actually starting it from a shortcut, you need to keep in
mind that the quoting rules for the shortcut target are those of the MS
CRT, which means you need to wrap single arguments containing whitespace
in double quotes and then backslash escape any double quotes (and
backslashes, of which we don't have any) inside those arguments.  This
will then be put into argv from mintty, which will exec bash with those
arguments it didn't consume itself, which means there needs to be no
extra level of quoting.  So that shortcut target becomes (undo the
linewrap):

C:\Freeware\Cygwin\bin\mintty.exe -e
 cd \$(\$(/bin/dirname \$(/bin/cygpath -u \$1\)\)\)\
  exec /bin/bash -i BashHere

The dir_argument gets filled in as the last argument by the dragdrop or
SendTo operation.



Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Eric Blake]

On 09/09/2014 03:15 AM, Achim Gratz wrote:

 
 If you want to get this right, you should work it out from the inside.
 You want the cd command to get a directory name from a subcommand that
 may contain spaces, so you need to quote the result:
 
 cd $( ... )
 

If you want to also guarantee that you can change to a relative
directory whose name begins with a -, you need:

cd -- $( ... )

 Since the argument you're getting may actually be a filename, you need
 to use the dirname command and quote its argument again:
 
 cd $(/bin/dirname $(...))

Again, if you have the possibility of a relative directory name that
might begin with dash,

cd -- $(/bin/dirname -- $(...))

 
 and dirname gets its argument from cygpath, and the argument to cygpath
 must itself be quoted again:
 
 cd $($(/bin/dirname $(/bin/cygpath -u $1)))

Ah - you are using cygpath, which can guarantee an absolute name (and
therefore avoid an argument beginning with dash).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: latest cygwin: 'run' problem

[Andrey Repin]

Greetings, Gary Johnson!

 @START  /D %~1 %~dp0\mintty.exe

  - run_bash_here.sh -
  

 This all is just not needed.
 Just create a shortcut in Sent to to your bash-here.cmd - job done, reap 
 the
 rewards.

 Thanks very much for the example.  It took me a while to figure out
 what that does.

The key parts are in 'set /?' and 'call /?'.
'cmd /?' is also a good read.

 I copied that line to bash-here.cmd and created a
 shortcut to it from my SendTo directory.  It almost works, but there
 are a few things my version does that yours does not.

 First, yours works only if you execute it while the target directory
 is selected in its parent directory.  Mine also works to run mintty
 in the current directory if you execute it while a file in that
 directory is selected.

That makes little sense. Could be solved, though. CMD doesn't offer a
way to distinguish between file and directory, but we have test.

@ECHO OFF
SETLOCAL
SET CYGWIN=nodosfilewarning
%~dp0\test.exe -f %~f1
ENDLOCAL
IF ERRORLEVEL 1 (
  SET DEST=%~f1
) ELSE (
  SET DEST=%~dp1
)

START  /D %DEST% %~dp0\mintty.exe

 Second, my version runs a login shell which sets up the environment
 correctly, e.g., puts /usr/local/bin:/usr/bin: at the head of PATH.

I already have environment correctly set at login. It's not like i'm logging
into random directories across my filesystem over and over again. I just start 
a shell where I need it.

 Just telling mintty to run a login shell isn't sufficient, however,
 because that also sets the current directory to your home directory,
 so you then need to cd to the target directory with the target path
 translated to Unix form.

That's why I don't start another login shell. It's inefficient. I already
logged it.

 Those issues may be easy to fix, but as I said, I don't know my way
 around cmd very well.

 It might actually be better if the script always started bash in the
 parent directory of the selected file.  That would be more
 consistent and could be simpler to implement.  I'll try to find an
 explanation of cmd parameter expansion and see what I can figure
 out.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 09.09.2014, 16:00

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: latest cygwin: 'run' problem

[Buchbinder, Barry (NIH/NIAID) [E]]

Andrey Repin sent the following at Tuesday, September 09, 2014 9:08 AM
That makes little sense. Could be solved, though. CMD doesn't offer a
way to distinguish between file and directory, but we have test.

Every directory contains a virtual file named nul (note: only one L;
serves the function of /dev/null ), so one can test for that.

c:\ if exist c:\Windows\nul echo y
y

c:\ if exist c:\Windows\explorer.exe\nul echo y

c:\

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Andrey Repin]

Greetings, Buchbinder, Barry (NIH/NIAID) [E]!

 Andrey Repin sent the following at Tuesday, September 09, 2014 9:08 AM
That makes little sense. Could be solved, though. CMD doesn't offer a
way to distinguish between file and directory, but we have test.

 Every directory contains a virtual file named nul (note: only one L;
 serves the function of /dev/null ), so one can test for that.

 c:\ if exist c:\Windows\nul echo y
 y

 c:\ if exist c:\Windows\explorer.exe\nul echo y

 c:\

NUL (or NUL:) is a DOS device. You CAN create a file called nul, though. But 
even then, the test fails.

$ VER  IF EXIST %SystemRoot%\nul ( ECHO y ) ELSE ( ECHO n )

Microsoft Windows [Version 6.1.7601]
n

$ ECHO.  \\.\%SystemRoot%\nul
$ DIR /B %SystemRoot%\n*
nul
notepad.exe
$ IF EXIST %SystemRoot%\nul ( ECHO y ) ELSE ( ECHO n )
n

However, you can test for %~f1\*. But since the behavior is not documented, 
you can't rely on such test either.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 09.09.2014, 18:22

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Gary Johnson]

On 2014-09-06, Gary Johnson wrote:
 On 2014-09-05, Gerry Reno wrote:
 
  To clarify this request a bit:
  
  Both run-1.2.0-1 and 1.3.1-1 are broken.  Neither one properly runs a 
  command.
  The only recent package that actually worked was run-1.3.0-1.
 
 That has not been my experience.  In my experience, run-1.2.0-1
 works fine but 1.3.0-1 was broken, so I've been keeping 1.2.0-1 on
 my system until I hear that run has been fixed.
 
 I'm sorry I don't have details on the problem with 1.3.0-1.  It
 would just not work with the commands I was trying to execute.  I
 believe there was some discussion about the issues on this list at
 the time 1.3.0-1 was released.  I'm at home at the moment and away
 from my Windows system so I can't experiment or look at the run
 commands I use.

I wrote a batch file and a shell script to implement a Run Bash Here
feature from the Windows file manager Send to context menu, much
like chere but without having to mess with the registry.  The
hardest part was getting the quoting in the run command line right
so that both cmd and bash were happy.  The files are included
in-line below.

When I updated to run-1.3, this stopped working.  That was a year
ago and I don't remember the symptoms exactly:  the window either
briefly appeared or there were no visible indications of the command
running at all.  I fiddled with the quoting for a while and finally
gave up and reverted to run-1.2.

I haven't tried the latest run-1.3.  I want to be sure I can still
revert to run-1.2 if 1.3 doesn't work.  I may be able to try it this
afternoon.

Regards,
Gary

 run_bash_here.bat -
@echo off

REM Batch file to run a bash shell in the directory given by the batchfile
REM argument, %1.
REM
REM Gary Johnson
REM 2006-10-17

REM Save the current value of CYGWIN and add the 'noglob' option to allow us
REM to pass the %1 argument to a bash command unchanged.
REM
set cygwin_save=%CYGWIN%
set CYGWIN=%CYGWIN% noglob

REM For the following, also set the Run Bash Here link in SendTo to run in a
REM minimized window to minimize the DOS window flash on startup.
REM
C:\cygwin\bin\run.exe /bin/mintty -e /bin/bash --login -c . run_bash_here.sh 
'%1' '%cygwin_save%'


- run_bash_here.sh -
# Run a Cygwin bash interactive shell in a directory according to the
# argument.  If the argument is a directory, run the shell there.  If the
# argument is a file, run the shell in the parent directory.  The argument is
# the full path in Windows format.

# Restore original value of CYGWIN.
#
CYGWIN=$2

# Convert first argument to a Cygwin path.
#
path=$(cygpath -u $1)

# If the path is not a directory, remove the last component.
#
if [ -d $path ]
then
dir=$path
else
dir=${path%/*}
fi

cd $dir
exec bash -i



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Gary Johnson]

On 2014-09-08, Gary Johnson wrote:
 On 2014-09-06, Gary Johnson wrote:
  On 2014-09-05, Gerry Reno wrote:
  
   To clarify this request a bit:
   
   Both run-1.2.0-1 and 1.3.1-1 are broken.  Neither one properly runs a 
   command.
   The only recent package that actually worked was run-1.3.0-1.
  
  That has not been my experience.  In my experience, run-1.2.0-1
  works fine but 1.3.0-1 was broken, so I've been keeping 1.2.0-1 on
  my system until I hear that run has been fixed.
  
  I'm sorry I don't have details on the problem with 1.3.0-1.  It
  would just not work with the commands I was trying to execute.  I
  believe there was some discussion about the issues on this list at
  the time 1.3.0-1 was released.  I'm at home at the moment and away
  from my Windows system so I can't experiment or look at the run
  commands I use.
 
 I wrote a batch file and a shell script to implement a Run Bash Here
 feature from the Windows file manager Send to context menu, much
 like chere but without having to mess with the registry.  The
 hardest part was getting the quoting in the run command line right
 so that both cmd and bash were happy.  The files are included
 in-line below.
 
 When I updated to run-1.3, this stopped working.  That was a year
 ago and I don't remember the symptoms exactly:  the window either
 briefly appeared or there were no visible indications of the command
 running at all.  I fiddled with the quoting for a while and finally
 gave up and reverted to run-1.2.
 
 I haven't tried the latest run-1.3.  I want to be sure I can still
 revert to run-1.2 if 1.3 doesn't work.  I may be able to try it this
 afternoon.

I tested the run command in my batch file by using my 64-bit Cygwin
installation to avoid breaking my 32-bit Cygwin installation.  (I
almost always use the 32-bit version because it originally had more
packages and I haven't seen any reason to switch.)  I first verified
that it worked with run-1.2, then upgraded to run-1.3.2-1.  It
failed.  Windows popped up, then disappeared.  I then added the
-ha option to mintty and ran the command again.  This time the
mintty window stayed and displayed this message:

run_bash_here.sh: line 0: .: filename argument required
.: usage: . filename [arguments]
/bin/bash: Exit 2

I'm going to continue using run-1.2.0-1 on my 32-bit Cygwin
installation because it just works.

Regards,
Gary


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Andrey Repin]

Greetings, Gary Johnson!

 I wrote a batch file and a shell script to implement a Run Bash Here
 feature from the Windows file manager Send to context menu, much
 like chere but without having to mess with the registry.  The
 hardest part was getting the quoting in the run command line right
 so that both cmd and bash were happy.  The files are included
 in-line below.

That's overengineered.

  run_bash_here.bat -
 

Replace it all with this bash-here.cmd placed in /bin :

@START  /D %~1 %~dp0\mintty.exe

 - run_bash_here.sh -
 

This all is just not needed.
Just create a shortcut in Sent to to your bash-here.cmd - job done, reap the
rewards.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 09.09.2014, 2:39

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Gary Johnson]

On 2014-09-09, Andrey Repin wrote:
 Greetings, Gary Johnson!
 
  I wrote a batch file and a shell script to implement a Run Bash Here
  feature from the Windows file manager Send to context menu, much
  like chere but without having to mess with the registry.  The
  hardest part was getting the quoting in the run command line right
  so that both cmd and bash were happy.  The files are included
  in-line below.
 
 That's overengineered.

Perhaps.  I know very little about Windows cmd shell programming, so
I tried to pass the file name to bash early in the process and
perform any logic there.

   run_bash_here.bat -
  
 
 Replace it all with this bash-here.cmd placed in /bin :
 
 @START  /D %~1 %~dp0\mintty.exe
 
  - run_bash_here.sh -
  
 
 This all is just not needed.
 Just create a shortcut in Sent to to your bash-here.cmd - job done, reap the
 rewards.

Thanks very much for the example.  It took me a while to figure out
what that does.  I copied that line to bash-here.cmd and created a
shortcut to it from my SendTo directory.  It almost works, but there
are a few things my version does that yours does not.

First, yours works only if you execute it while the target directory
is selected in its parent directory.  Mine also works to run mintty
in the current directory if you execute it while a file in that
directory is selected.

Second, my version runs a login shell which sets up the environment
correctly, e.g., puts /usr/local/bin:/usr/bin: at the head of PATH.
Just telling mintty to run a login shell isn't sufficient, however,
because that also sets the current directory to your home directory,
so you then need to cd to the target directory with the target path
translated to Unix form.

Those issues may be easy to fix, but as I said, I don't know my way
around cmd very well.

It might actually be better if the script always started bash in the
parent directory of the selected file.  That would be more
consistent and could be simpler to implement.  I'll try to find an
explanation of cmd parameter expansion and see what I can figure
out.

Regards,
Gary


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Gary Johnson]

On 2014-09-08, Gary Johnson wrote:
 On 2014-09-09, Andrey Repin wrote:
  Greetings, Gary Johnson!
  
   I wrote a batch file and a shell script to implement a Run Bash Here
   feature from the Windows file manager Send to context menu, much
   like chere but without having to mess with the registry.  The
   hardest part was getting the quoting in the run command line right
   so that both cmd and bash were happy.  The files are included
   in-line below.
  
  That's overengineered.
 
 Perhaps.  I know very little about Windows cmd shell programming, so
 I tried to pass the file name to bash early in the process and
 perform any logic there.
 
    run_bash_here.bat -
   
  
  Replace it all with this bash-here.cmd placed in /bin :
  
  @START  /D %~1 %~dp0\mintty.exe
  
   - run_bash_here.sh -
   
  
  This all is just not needed.
  Just create a shortcut in Sent to to your bash-here.cmd - job done, reap 
  the
  rewards.
 
 Thanks very much for the example.  It took me a while to figure out
 what that does.  I copied that line to bash-here.cmd and created a
 shortcut to it from my SendTo directory.  It almost works, but there
 are a few things my version does that yours does not.
 
 First, yours works only if you execute it while the target directory
 is selected in its parent directory.  Mine also works to run mintty
 in the current directory if you execute it while a file in that
 directory is selected.
 
 Second, my version runs a login shell which sets up the environment
 correctly, e.g., puts /usr/local/bin:/usr/bin: at the head of PATH.
 Just telling mintty to run a login shell isn't sufficient, however,
 because that also sets the current directory to your home directory,
 so you then need to cd to the target directory with the target path
 translated to Unix form.
 
 Those issues may be easy to fix, but as I said, I don't know my way
 around cmd very well.
 
 It might actually be better if the script always started bash in the
 parent directory of the selected file.  That would be more
 consistent and could be simpler to implement.  I'll try to find an
 explanation of cmd parameter expansion and see what I can figure
 out.

After much fiddling (programming by successive approximation), I
came up with this:

@START  C:\cygwin\bin\mintty.exe /bin/bash --login -c cd $(cygpath -u 
$0); exec bash -i %~p1\

Using an explicit path to mintty lets me put the script itself
someplace other than /bin.

Because %~p1 ends with a backslash, I had to add another backslash
before the closing quote to prevent the quote from being included in
the path.  (See http://ss64.com/nt/syntax-args.html and
http://ss64.com/nt/syntax-esc.html#escape.)

I haven't tried it yet with a path that includes a space.  Tomorrow.

Regards,
Gary


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Andrey Repin]

Greetings, Gary Johnson!

 To clarify this request a bit:
 
 Both run-1.2.0-1 and 1.3.1-1 are broken.  Neither one properly runs a 
 command.
 The only recent package that actually worked was run-1.3.0-1.

 That has not been my experience.  In my experience, run-1.2.0-1
 works fine but 1.3.0-1 was broken, so I've been keeping 1.2.0-1 on
 my system until I hear that run has been fixed.

 I'm sorry I don't have details on the problem with 1.3.0-1.

The details are simple: It. just. core. dump.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 07.09.2014, 18:46

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Andrey Repin]

Greetings, Gerry Reno!

 On 09/06/2014 04:12 PM, Gary Johnson wrote:
 On 2014-09-05, Gerry Reno wrote:

 To clarify this request a bit:

 Both run-1.2.0-1 and 1.3.1-1 are broken.  Neither one properly runs a 
 command.
 The only recent package that actually worked was run-1.3.0-1.
 That has not been my experience.  In my experience, run-1.2.0-1
 works fine but 1.3.0-1 was broken, so I've been keeping 1.2.0-1 on
 my system until I hear that run has been fixed.

 I'm sorry I don't have details on the problem with 1.3.0-1.  It
 would just not work with the commands I was trying to execute.  I
 believe there was some discussion about the issues on this list at
 the time 1.3.0-1 was released.  I'm at home at the moment and away
 from my Windows system so I can't experiment or look at the run
 commands I use.

 Regards,
 Gary




 Here, make this work with run-1.2.0-1 or run-1.3.1-1 and you'll
 make a believer out of me.

 run $WINDIR/system32/mstsc.exe /multimon /v:$IP:3389

Not with 1.3.1

Command Line:
C:\WINDOWS\system32\mstsc.exe /multimon /v:IP:3389

Here's the problem, as Achim said.

 And until such time as somebody actually gets around to fixing
 'run' it would be nice if there was an alternate choice of
 run-1.3.0-1 that just seems to work with every command
 I feed it.

cmd.exe /C START  /B $WINDIR/system32/mstsc.exe /multimon /v:$IP:3389


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 07.09.2014, 18:48

Sorry for my terrible english...


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[David Stacey]

On 06/09/14 02:14, Gerry Reno wrote:

Can run-1.3.0-1 be added back into the Setup as an alternate choice until 'run' 
can be fixed?


You should be able to get run-1.3.0 from the Cygwin Time Machine [1]. 
Based on the file timestamps of various versions of 'run', try dates in 
the range August 2013 to May 2014.


Dave.

[1] - http://www.fruitbat.org/Cygwin/#cygwintimemachine


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Gary Johnson]

On 2014-09-05, Gerry Reno wrote:

 To clarify this request a bit:
 
 Both run-1.2.0-1 and 1.3.1-1 are broken.  Neither one properly runs a command.
 The only recent package that actually worked was run-1.3.0-1.

That has not been my experience.  In my experience, run-1.2.0-1
works fine but 1.3.0-1 was broken, so I've been keeping 1.2.0-1 on
my system until I hear that run has been fixed.

I'm sorry I don't have details on the problem with 1.3.0-1.  It
would just not work with the commands I was trying to execute.  I
believe there was some discussion about the issues on this list at
the time 1.3.0-1 was released.  I'm at home at the moment and away
from my Windows system so I can't experiment or look at the run
commands I use.

Regards,
Gary


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Gerry Reno]

On 09/06/2014 04:12 PM, Gary Johnson wrote:
 On 2014-09-05, Gerry Reno wrote:

 To clarify this request a bit:

 Both run-1.2.0-1 and 1.3.1-1 are broken.  Neither one properly runs a 
 command.
 The only recent package that actually worked was run-1.3.0-1.
 That has not been my experience.  In my experience, run-1.2.0-1
 works fine but 1.3.0-1 was broken, so I've been keeping 1.2.0-1 on
 my system until I hear that run has been fixed.

 I'm sorry I don't have details on the problem with 1.3.0-1.  It
 would just not work with the commands I was trying to execute.  I
 believe there was some discussion about the issues on this list at
 the time 1.3.0-1 was released.  I'm at home at the moment and away
 from my Windows system so I can't experiment or look at the run
 commands I use.

 Regards,
 Gary




Here, make this work with run-1.2.0-1 or run-1.3.1-1 and you'll
make a believer out of me.

run $WINDIR/system32/mstsc.exe /multimon /v:$IP:3389

And until such time as somebody actually gets around to fixing
'run' it would be nice if there was an alternate choice of
run-1.3.0-1 that just seems to work with every command
I feed it.

Gerry



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Gerry Reno]

On 09/03/2014 03:48 PM, Achim Gratz wrote:
 Gerry Reno writes:
 On the 32-bit system cygwin installs that haven't been updated yet 'run.exe' 
 shows:

 $ ls -l /usr/bin/run.exe
 -rwxr-xr-x 1 Administrator None 65053 Jul 24  2013 /usr/bin/run.exe

 On a 32-bit system with this latest cygwin 'run.exe' shows:

 $ ls -l /usr/bin/run.exe
 -rwxr-xr-x 1 SYSTEM SYSTEM 66077 Jun  9 13:16 /usr/bin/run.exe

 Filesize is different so something has changed there.
 A cygcheck -f /usr/bin/run.exe would be more enlightening, although I
 think the two versions of run should be 1.3.0 and 1.3.1.  If so then the
 reason for mstsc not recognizing the options would be the patch by Max
 Polk that quotes all the arguments (the change description said it'd
 quote only arguments with spaces in them, but the code actually quotes
 all of them anyway).  This also means that mstsc seems to implement its
 own version of options processing or argument quoting (probably the
 former since options to mstsc need not be quoted).  The quoting function
 in the current version of run is too naive anyway, so I'll have to
 update it with something more sensible.  It'll be a few days, sorry for
 the inconvenience.


 Regards,
 Achim.

Can run-1.3.0-1 be added back into the Setup as an alternate choice until 'run' 
can be fixed?

Gerry


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Gerry Reno]

On 09/05/2014 09:14 PM, Gerry Reno wrote:
 On 09/03/2014 03:48 PM, Achim Gratz wrote:
 Gerry Reno writes:
 On the 32-bit system cygwin installs that haven't been updated yet 
 'run.exe' shows:

 $ ls -l /usr/bin/run.exe
 -rwxr-xr-x 1 Administrator None 65053 Jul 24  2013 /usr/bin/run.exe

 On a 32-bit system with this latest cygwin 'run.exe' shows:

 $ ls -l /usr/bin/run.exe
 -rwxr-xr-x 1 SYSTEM SYSTEM 66077 Jun  9 13:16 /usr/bin/run.exe

 Filesize is different so something has changed there.
 A cygcheck -f /usr/bin/run.exe would be more enlightening, although I
 think the two versions of run should be 1.3.0 and 1.3.1.  If so then the
 reason for mstsc not recognizing the options would be the patch by Max
 Polk that quotes all the arguments (the change description said it'd
 quote only arguments with spaces in them, but the code actually quotes
 all of them anyway).  This also means that mstsc seems to implement its
 own version of options processing or argument quoting (probably the
 former since options to mstsc need not be quoted).  The quoting function
 in the current version of run is too naive anyway, so I'll have to
 update it with something more sensible.  It'll be a few days, sorry for
 the inconvenience.


 Regards,
 Achim.
 Can run-1.3.0-1 be added back into the Setup as an alternate choice until 
 'run' can be fixed?

 Gerry


To clarify this request a bit:

Both run-1.2.0-1 and 1.3.1-1 are broken.  Neither one properly runs a command.
The only recent package that actually worked was run-1.3.0-1.

Gerry


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Gerry Reno]

On 09/02/2014 08:59 PM, Gerry Reno wrote:
 On 09/02/2014 01:50 PM, Marco Atzeri wrote:

 On 02/09/2014 19:37, Achim Gratz wrote:
 Gerry Reno writes:
 I have a script that issues this command:

  run $WINDIR/system32/mstsc.exe  /multimon /v:$IP:3389


 And before this script has always succeeded but now it errors as follows:

  Invalid connection file (/v:192.168.1.27:3389) specified

 In a terminal window I can run the command directly and it succeeds:

  $WINDIR/system32/mstsc.exe  /multimon /v:$IP:3389

 But 'run' no longer successfully runs the command.

 Can someone verify this?
 Well I can verify that this happens, but I have no idea why.  It seems
 that mstsc doesn't parse the option as option when  started via run…


 Regards,
 Achim.

 I noticed that

  run $WINDIR/system32/mstsc.exe  /multimon /v:my_ip:3389

 produces equivalent output of

  mstsc.exe  /multimon /v:my_ip:3389

 so eventually run is splitting the arguments in a way that mstsc
 does not like

 Marco


 It looks like it's always taking the last argument as a file.

 No matter what you put at the end of the line 'run' causes mstsc to think 
 it's a file that needs opened.

 Gerry


 --

On the 32-bit system cygwin installs that haven't been updated yet 'run.exe' 
shows:

$ ls -l /usr/bin/run.exe
-rwxr-xr-x 1 Administrator None 65053 Jul 24  2013 /usr/bin/run.exe

On a 32-bit system with this latest cygwin 'run.exe' shows:

$ ls -l /usr/bin/run.exe
-rwxr-xr-x 1 SYSTEM SYSTEM 66077 Jun  9 13:16 /usr/bin/run.exe

Filesize is different so something has changed there.


Gerry



--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Mark Geisert]

Gerry Reno writes:
[...]
 On the 32-bit system cygwin installs that haven't been updated yet
'run.exe' shows:
 
 $ ls -l /usr/bin/run.exe
 -rwxr-xr-x 1 Administrator None 65053 Jul 24  2013 /usr/bin/run.exe
 
 On a 32-bit system with this latest cygwin 'run.exe' shows:
 
 $ ls -l /usr/bin/run.exe
 -rwxr-xr-x 1 SYSTEM SYSTEM 66077 Jun  9 13:16 /usr/bin/run.exe
 
 Filesize is different so something has changed there.

'run' is in its own package so 'cygcheck -c run' on your systems would
probably show different version numbers.  But I suspect we are all idling
until the 'run' maintainer chimes in.

..mark


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Achim Gratz]

Gerry Reno writes:
 On the 32-bit system cygwin installs that haven't been updated yet 'run.exe' 
 shows:

 $ ls -l /usr/bin/run.exe
 -rwxr-xr-x 1 Administrator None 65053 Jul 24  2013 /usr/bin/run.exe

 On a 32-bit system with this latest cygwin 'run.exe' shows:

 $ ls -l /usr/bin/run.exe
 -rwxr-xr-x 1 SYSTEM SYSTEM 66077 Jun  9 13:16 /usr/bin/run.exe

 Filesize is different so something has changed there.

A cygcheck -f /usr/bin/run.exe would be more enlightening, although I
think the two versions of run should be 1.3.0 and 1.3.1.  If so then the
reason for mstsc not recognizing the options would be the patch by Max
Polk that quotes all the arguments (the change description said it'd
quote only arguments with spaces in them, but the code actually quotes
all of them anyway).  This also means that mstsc seems to implement its
own version of options processing or argument quoting (probably the
former since options to mstsc need not be quoted).  The quoting function
in the current version of run is too naive anyway, so I'll have to
update it with something more sensible.  It'll be a few days, sorry for
the inconvenience.


Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Gerry Reno]

On 09/03/2014 03:48 PM, Achim Gratz wrote:
 cygcheck -f /usr/bin/run.exe

Working systems:

$ cygcheck -f /usr/bin/run.exe
run-1.3.0-1

Broken systems:

$ cygcheck -f /usr/bin/run.exe
run-1.3.1-1


Your guess was correct.

Gerry





--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

latest cygwin: 'run' problem

[Gerry Reno]

I just updated to the latest cygwin via setup and now my run commands are 
failing.

I have a script that issues this command:

run $WINDIR/system32/mstsc.exe  /multimon /v:$IP:3389


And before this script has always succeeded but now it errors as follows:

Invalid connection file (/v:192.168.1.27:3389) specified

In a terminal window I can run the command directly and it succeeds:

$WINDIR/system32/mstsc.exe  /multimon /v:$IP:3389

But 'run' no longer successfully runs the command.

Can someone verify this?


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Achim Gratz]

Gerry Reno writes:
 I have a script that issues this command:

 run $WINDIR/system32/mstsc.exe  /multimon /v:$IP:3389


 And before this script has always succeeded but now it errors as follows:

 Invalid connection file (/v:192.168.1.27:3389) specified

 In a terminal window I can run the command directly and it succeeds:

 $WINDIR/system32/mstsc.exe  /multimon /v:$IP:3389

 But 'run' no longer successfully runs the command.

 Can someone verify this?

Well I can verify that this happens, but I have no idea why.  It seems
that mstsc doesn't parse the option as option when  started via run…


Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Marco Atzeri]

On 02/09/2014 19:37, Achim Gratz wrote:

Gerry Reno writes:

I have a script that issues this command:

 run $WINDIR/system32/mstsc.exe  /multimon /v:$IP:3389


And before this script has always succeeded but now it errors as follows:

 Invalid connection file (/v:192.168.1.27:3389) specified

In a terminal window I can run the command directly and it succeeds:

 $WINDIR/system32/mstsc.exe  /multimon /v:$IP:3389

But 'run' no longer successfully runs the command.

Can someone verify this?


Well I can verify that this happens, but I have no idea why.  It seems
that mstsc doesn't parse the option as option when  started via run…


Regards,
Achim.



I noticed that

 run $WINDIR/system32/mstsc.exe  /multimon /v:my_ip:3389

produces equivalent output of

 mstsc.exe  /multimon /v:my_ip:3389

so eventually run is splitting the arguments in a way that mstsc
does not like

Marco


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: latest cygwin: 'run' problem

[Gerry Reno]

On 09/02/2014 01:50 PM, Marco Atzeri wrote:


 On 02/09/2014 19:37, Achim Gratz wrote:
 Gerry Reno writes:
 I have a script that issues this command:

  run $WINDIR/system32/mstsc.exe  /multimon /v:$IP:3389


 And before this script has always succeeded but now it errors as follows:

  Invalid connection file (/v:192.168.1.27:3389) specified

 In a terminal window I can run the command directly and it succeeds:

  $WINDIR/system32/mstsc.exe  /multimon /v:$IP:3389

 But 'run' no longer successfully runs the command.

 Can someone verify this?

 Well I can verify that this happens, but I have no idea why.  It seems
 that mstsc doesn't parse the option as option when  started via run…


 Regards,
 Achim.


 I noticed that

  run $WINDIR/system32/mstsc.exe  /multimon /v:my_ip:3389

 produces equivalent output of

  mstsc.exe  /multimon /v:my_ip:3389

 so eventually run is splitting the arguments in a way that mstsc
 does not like

 Marco



It looks like it's always taking the last argument as a file.

No matter what you put at the end of the line 'run' causes mstsc to think it's 
a file that needs opened.

Gerry


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple