latest cygwin: 'run' problem

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

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

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

[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 "keep"ing 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 "keep"ing 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

[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 "keep"ing 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 (anrdaemon@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

[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 "keep"ing 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 (anrdaemon@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

[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 "keep"ing 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 "keep"ing 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 (anrdaemon@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

[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 drag&drop 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]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

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 (anrdaemon@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 (anrdaemon@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

[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