Re: Messages not delivered to the cygwin@ mailing list

[Ernie Rael via Cygwin]

On 23/09/15 1:59 PM, Andrey Repin via Cygwin wrote:

Greetings, cygwin-ow...@cygwin.com!

It is about 4 months since I lost ability to post to the many mailing lists
from my primary address. Messages are seemingly coming into a blackhole - no
responses, no rejections, nada.
The subscription is working, I'm receiving all mails that are coming through
the list, except my own.
I've tried to contact my service provider and they said the messages are
leaving their system all right.
Can you please check if they are arriving safely?


I've experienced something similar with one or two of the lists I 
subscribe to. It only happens with a mailing list that shows my personal 
email address as "From".


I use a mail server, there are DNS MX records that direct my mail to the 
mail server. I use firefox POP to access the mail server and I send mail 
with SMTP through the mail server. The email from the mailing list that 
never makes it to my home firefox is on my mail server (I've looked at 
the list archive, it's there; I can log in to the mail server and see it 
there). I suspect that since it has my address as "From" it is not 
picked up by firefox; either due to a mail server issue or a firefox 
issue, possibly because I haven't configured something correctly on one 
or the other.


I think it started when I changed to a different mail server (and I 
don't want to change again). It hasn't been enough of a problem to spend 
a lot of time tracking it down. If you do determine what's going on with 
your email, I'd appreciate hearing about it.


-ernie


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

Re: sshd

[Ernie Rael]

On 2/13/22 10:56 PM, Andrey Repin wrote:

Greetings, Ernie Rael!

...
Open Windows Firewall (cygstart WF.msc), find all your sshd rules and trash
them. Manually create (or tweak Windows sshd one) a single rule for port
rather than executable.
Additionally, to resolve conflicts with stock sshd, create a file
%ProgramData%\ssh\sshd_config with single line `Port 2022` (for example).



Bingo. Many thanks.

I'd never opened the Windows Firewall before (IIRC), I didn't get the 
other references, looking around I ran into some windows defender thing, 
that said it had never run before, so I ignored it and figured it wasn't 
the firewall. I didn't realize the firewall was so pervasive.


Anyway, I found some sshd rules that referenced "C:/cygwin64/..." and a 
few years back I'd reinstalled cygwin on F: to get it off of C:, but the 
rules were never updated. So change "C" to "F" in a couple spots and now 
it connects.


Thanks again,
-ernie

PS Now I can track down why rsync asks for a passwd but ssh doesn't :-)



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

Re: sshd

[Ernie Rael]

Thanks Russell,
cygrunsrv's running

$ cygrunsrv --list
sshd

$ cygrunsrv --query sshd
Service : sshd
Display name    : CYGWIN sshd
Current State   : Running
Controls Accepted   : Stop
Command : /usr/sbin/sshd -D


-ernie

On 2/12/22 10:30 PM, Russell VT wrote:

Note that port 5972 isn't *really* what you want, as that's arbitrary...
but port 22.

Check the Windows firewall, as was already suggested (highly suspect, if
you just timeout when trying to connect).

If you try rebuilding what you did under Windows, you're likely going to
want to look at *cygserver* and *cygrunsrv*, and NOT directly at sshd. It's
in /usr/sbin, generally.

Something like:

$ cygrunsrv --list
cygsshd

$ cygrunsrv --query cygsshd
Service : cygsshd
Display name: CYGWIN cygsshd
Current State   : Stopped
Command : /usr/sbin/sshd -D


You might also look to the Windows System Utilities / Sysinternals
<https://docs.microsoft.com/en-us/sysinternals/> (optional download), and
the "Process Explorer" for more detailed Windows information at the tips of
your fingers. They update every month or two, and are worth keeping
"reasonably up to date." There's a plethora of Windows troubleshooting
tools, and some fun stuff as-well.

Cheers -
Russell







On Sat, Feb 12, 2022 at 9:30 PM Mark Geisert  wrote:


Ernie Rael wrote:

Hi all,

I set up cygwin several years ago and have only had one system at home.

I've

recently got a 2nd, linux.

I've used ssh locally under cygwin, primarily to get a term for a use

with admin

priv. And I can ssh from cygwin to the linux machine. On cygwin I see

 $ ps -ef |grep sshd
 cyg_serv 255 254 ?  Feb  1 /usr/sbin/sshd

But ssh from linux to cygwin hangs (finally times out). Ping works linux

--> windows.

I must have run ssh-host-config way back when. Can I just run it again?

Suggestions for something else to try and/or triage the problem?

You might try the following.  Determine the Windows pid of your sshd
process, then
use netstat to see if that process is listening on the sshd port.  Here's
what a
successful check looks like:

~ ps -as|grep sshd
42834 ?  Jan 16 /usr/sbin/sshd

~ ps -lp 42834
PIDPPIDPGID WINPID   TTY UIDSTIME COMMAND
  42834   42832   42834   5972  ? 197612   Jan 16
/usr/sbin/sshd

~ netstat -ao|grep 5972
TCP0.0.0.0:22 zotac:0LISTENING
  5972
TCP[::]:22zotac:0LISTENING
  5972

If the two output lines aren't there, I'd suspect a Windows firewall has
TCP port
22 walled off.  ("zotac" is my machine name; you'll see something
different there.)
HTH,

..mark

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






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

Re: sshd

[Ernie Rael]

On 2/12/22 9:29 PM, Mark Geisert wrote:

Ernie Rael wrote:

Hi all,

I set up cygwin several years ago and have only had one system at 
home. I've recently got a 2nd, linux.


I've used ssh locally under cygwin, primarily to get a term for a use 
with admin priv. And I can ssh from cygwin to the linux machine. On 
cygwin I see


    $ ps -ef |grep sshd
    cyg_serv 255 254 ?  Feb  1 /usr/sbin/sshd

But ssh from linux to cygwin hangs (finally times out). Ping works 
linux --> windows.


I must have run ssh-host-config way back when. Can I just run it again?

Suggestions for something else to try and/or triage the problem?


You might try the following.  Determine the Windows pid of your sshd 
process, then use netstat to see if that process is listening on the 
sshd port.  Here's what a successful check looks like:


~ ps -as|grep sshd
  42834 ?  Jan 16 /usr/sbin/sshd

~ ps -lp 42834
  PID    PPID    PGID WINPID   TTY UID    STIME COMMAND
    42834   42832   42834   5972  ? 197612   Jan 16 
/usr/sbin/sshd


~ netstat -ao|grep 5972
  TCP    0.0.0.0:22 zotac:0 LISTENING   5972
  TCP    [::]:22    zotac:0 LISTENING   5972

If the two output lines aren't there, I'd suspect a Windows firewall 
has TCP port 22 walled off.  ("zotac" is my machine name; you'll see 
something different there.)

HTH,

..mark


Thanks Mark,

Doesn't seem to be a firewall issue. NetStat took about 90 seconds.

$ ps -lp 255
  PID    PPID    PGID WINPID   TTY UID    STIME COMMAND
  255 254 255   4176  ?   1006   Feb  1 
/usr/sbin/sshd


$ netstat -ao | grep 4176
  TCP    0.0.0.0:22 spirit:0 LISTENING   4176
  TCP    [::]:22    spirit:0 LISTENING   4176


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

sshd

[Ernie Rael]

Hi all,

I set up cygwin several years ago and have only had one system at home. 
I've recently got a 2nd, linux.


I've used ssh locally under cygwin, primarily to get a term for a use 
with admin priv. And I can ssh from cygwin to the linux machine. On 
cygwin I see


   $ ps -ef |grep sshd
   cyg_serv 255 254 ?  Feb  1 /usr/sbin/sshd

But ssh from linux to cygwin hangs (finally times out). Ping works linux 
--> windows.


I must have run ssh-host-config way back when. Can I just run it again?

Suggestions for something else to try and/or triage the problem?

-ernie


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

Re: Bug Report

[Ernie Rael]

On 2/8/22 2:01 PM, julie77...@gmail.com wrote:

Cygwin doesn't create an environment variable in bash to indicate that the
platform is Cygwin under Windows.

This causes compatibility problems when running various tools. Most of my
issues have been with Python tools running Windows Python.

I have been addressing this issue by grepping PATH for cygdrive which
doesn't seem like a very good approach.

Both msys2 and mingw solve this issue by setting the MSYSTEM environment
variable which lets tools check that OS=Windows_NT and MSYSTEM=MSYS

Please add some way of identifying that programs are running under Cygwin.


And of course there's

   $ uname -o
   Cygwin

-ernie


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

Re: sshd.exe infected with IDP.Generic?

[Ernie Rael]

Thanks for response Marco and Brian.

I guess I'll chalk up to coincidence the "rm *" that I didn't knowingly 
type (it was in the typeahead buffer when less finally finished and I 
had been "randomly" hitting keys to get it to end) followed shortly 
thereafter by avast moving sshd.exe to quarantine. I suppose the command 
could have mysteriously come from some history since I do use the rm 
command regularly ;-) Hmm, use -I? I lost almost nothing since the admin 
acct in cygwin's /home is only used for ssh to local and there are 
backups to look at.


As far as getting things back to normal...

Asking avast to "put it back" failed. I did "extract" it, but 
owner/permissions seem screwed up.

$ ls -l sshd.exe
rwxr-x+ 1 Administrators SYSTEM 721939 Feb 18 09:05 sshd.exe
I put it back, with u+rx, ran cygwin's setup and it's package had been 
updated recently, sshd was updated, and things seem back to normal. 
First I had virus scanned the entire system, took all day, it did find 
something in an archived copy of a system I had 10 years ago.


-ernie

PS virustotal is cool
https://www.virustotal.com/gui/file/8cba0094cf589c9b39c6814ae11e7fc32e0d9988e280004b6a18ca7e2014c71d/detection

On 7/10/2020 12:01 PM, Ernie Rael wrote:
On Win7. To get an elevated shell, I typically do "$ ssh xxx@yyy". And 
not very often.


Below is an excerpt of something potentially horrible that just happened.

Note the

   rm *

I exited the shell. I did the "ssh..." again (yeah I'm crazy), in a 
different bash window. And this time avast reported that it stashed 
sshd.exe into the virus chest.


I'm not sure who/what the culprit is, or what's going on. But it does 
look like there was (is?) some kind of infection somewhere on my 
system. I had used ftp earlier to put a file to a remote, but...?


I didn't realize that netstat was a windows command (not that I 
wouldn't have used it).


I've got the sshd.exe file. It has a date of Feb 18. So

 * Can I check if the bits in sshd.exe are as expected?
 * Any suggestions on cleaning up and/or restoring sanity? (I'm running
   a full virus scan right now, should be amusing...)
 * How can I get sshd.exe back? Is there a cygwin command to check that
   the packages are all as they should be?

-ernie

=== EXCERPT ==



$ ssh xxx@yyy
Last login: Mon May 18 21:37:37 2020 from 192.168.0.11
  , __
   .L_ |  |
 .gQQQ__ 
|  |

 

ADMIN ~
$ netstat -b -a | less


# worked but had to ^Z/kill to get out

ADMIN ~
$

ADMIN ~
$

ADMIN ~
$ rm *
rm: cannot remove 'play': Is a directory
rm: cannot remove 'system': Is a directory

ADMIN erra@spirit ~
$


ADMIN ~/play
$ netstat -b -a | less

# let netstat complete normally, got out of 
less ok



ADMIN ~/play
$ client_loop: send disconnect: Connection reset by peer


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



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

sshd.exe infected with IDP.Generic?

[Ernie Rael]

On Win7. To get an elevated shell, I typically do "$ ssh xxx@yyy". And 
not very often.


Below is an excerpt of something potentially horrible that just happened.

Note the

   rm *

I exited the shell. I did the "ssh..." again (yeah I'm crazy), in a 
different bash window. And this time avast reported that it stashed 
sshd.exe into the virus chest.


I'm not sure who/what the culprit is, or what's going on. But it does 
look like there was (is?) some kind of infection somewhere on my system. 
I had used ftp earlier to put a file to a remote, but...?


I didn't realize that netstat was a windows command (not that I wouldn't 
have used it).


I've got the sshd.exe file. It has a date of Feb 18. So

 * Can I check if the bits in sshd.exe are as expected?
 * Any suggestions on cleaning up and/or restoring sanity? (I'm running
   a full virus scan right now, should be amusing...)
 * How can I get sshd.exe back? Is there a cygwin command to check that
   the packages are all as they should be?

-ernie

=== EXCERPT ==



$ ssh xxx@yyy
Last login: Mon May 18 21:37:37 2020 from 192.168.0.11
  , __
   .L_ |  |
 .gQQQ__ 
|  |

 

ADMIN ~
$ netstat -b -a | less


# worked but had to ^Z/kill to get out

ADMIN ~
$

ADMIN ~
$

ADMIN ~
$ rm *
rm: cannot remove 'play': Is a directory
rm: cannot remove 'system': Is a directory

ADMIN erra@spirit ~
$


ADMIN ~/play
$ netstat -b -a | less

# let netstat complete normally, got out of 
less ok



ADMIN ~/play
$ client_loop: send disconnect: Connection reset by peer


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

FYI: avast claims setup threat

[Ernie Rael]

I just downloaded most recent setup-x86_64, v2.903. Avast was not happy.

   Threat name: IDP.Generic

I did check with pgp2 --verify before I tried it.

-ernie

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

How to get the drive a file is on (was Re: /bin/pwd, cygpath -wa fail under native symlink)

[Ernie Rael]

I need to find out the drive on which some files reside.

I need to make some links from a tmp dir to the files from a script. So 
I need to determine where they reside so I can figure out which tmp dir 
to use. Hard links, not running as administrator.


I tried cygpath -wa and /bin/pwd. They fail in some cases as described 
below. If this is a problem for cygwin, is there a win7 command I can use?


-ernie

On 12/25/2019 2:05 PM, Ernie Rael wrote:
(CYGWIN_NT-6.1 spirit 3.1.1(0.340/5/3) 2019-12-18 09:28 x86_64 Cygwin, 
win7)


The windows root is C:, cygwin root is on F:.
A native symlink under C: that points into F: gets
an incorrect result from cygpath -wa.

Notice that when the current directory is the target of the symlink
then the result is ok. But any deeper in the tree fails. To summarize:

    @ /a/src/jvi-dev/jvi
$ cygpath -wa .
C:\f\src\jvi-dev\jvi <<<<<<< correct
    @ /a/src/jvi-dev/jvi/src
$ cygpath -wa .
C:\a\src\jvi-dev\jvi\src <<<<<<< fail

=== more detail ===

    @ /a/src/jvi-dev
$ ls -l jvi
lrwxrwxrwx 1 erra None 18 Dec 23 15:16 jvi -> /f/src/jvi-dev/jvi

    @ /a/src/jvi-dev
$ junction jvi

Junction v1.06 - Windows junction creator and reparse point viewer
Copyright (C) 2000-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\a\src\jvi-dev\jvi: SYMBOLIC LINK
   Print Name : C:\f\src\jvi-dev\jvi
   Substitute Name: \??\C:\f\src\jvi-dev\jvi

    @ /a/src/jvi-dev
$ cygpath -wa jvi
C:\a\src\jvi-dev\jvi

    @ /a/src/jvi-dev
$ cd jvi

    @ /a/src/jvi-dev/jvi
$ cygpath -wa .
C:\f\src\jvi-dev\jvi <<<<<<< correct

    @ /a/src/jvi-dev/jvi
$ cd src

    @ /a/src/jvi-dev/jvi/src
$ cygpath -wa .
C:\a\src\jvi-dev\jvi\src <<<<<<< fail

=== some possibly relevent stuff from the mount table

$ mount
F:/cygwin64 on / type ntfs (binary,auto)
C:/f on /f type ntfs (binary,user)
F:/c on /c type ntfs (binary,user)
F: on /cygdrive/f type ntfs (binary,posix=0,user,noumount,auto)


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






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

/bin/pwd, cygpath -wa fail under native symlink

[Ernie Rael]

(CYGWIN_NT-6.1 spirit 3.1.1(0.340/5/3) 2019-12-18 09:28 x86_64 Cygwin, win7)

The windows root is C:, cygwin root is on F:.
A native symlink under C: that points into F: gets
an incorrect result from cygpath -wa.

Notice that when the current directory is the target of the symlink
then the result is ok. But any deeper in the tree fails. To summarize:

    @ /a/src/jvi-dev/jvi
$ cygpath -wa .
C:\f\src\jvi-dev\jvi <<< correct
    @ /a/src/jvi-dev/jvi/src
$ cygpath -wa .
C:\a\src\jvi-dev\jvi\src <<< fail

=== more detail ===

    @ /a/src/jvi-dev
$ ls -l jvi
lrwxrwxrwx 1 erra None 18 Dec 23 15:16 jvi -> /f/src/jvi-dev/jvi

    @ /a/src/jvi-dev
$ junction jvi

Junction v1.06 - Windows junction creator and reparse point viewer
Copyright (C) 2000-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\a\src\jvi-dev\jvi: SYMBOLIC LINK
   Print Name : C:\f\src\jvi-dev\jvi
   Substitute Name: \??\C:\f\src\jvi-dev\jvi

    @ /a/src/jvi-dev
$ cygpath -wa jvi
C:\a\src\jvi-dev\jvi

    @ /a/src/jvi-dev
$ cd jvi

    @ /a/src/jvi-dev/jvi
$ cygpath -wa .
C:\f\src\jvi-dev\jvi <<< correct

    @ /a/src/jvi-dev/jvi
$ cd src

    @ /a/src/jvi-dev/jvi/src
$ cygpath -wa .
C:\a\src\jvi-dev\jvi\src <<< fail

=== some possibly relevent stuff from the mount table

$ mount
F:/cygwin64 on / type ntfs (binary,auto)
C:/f on /f type ntfs (binary,user)
F:/c on /c type ntfs (binary,user)
F: on /cygdrive/f type ntfs (binary,posix=0,user,noumount,auto)


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

setup postinstall mimeinfo errors

[Ernie Rael]

During setup postinstall I got a couple of errors; it looks like they 
are related to mimeinfo/mimeinfo.cache. (It is true that I did not 
accept all dependencies but I thought I was being careful).


I went back into setup and it shows that I have "shared-mime-info: 
Shared MIME info database" 1.7-1 from X11 category.


Is there something I should do to insure things are OK/clean?

-ernie

2017/06/10 09:38:03 running: F:\cygwin64\bin\bash.exe --norc --noprofile 
"/etc/postinstall/zp_desktop-file-utils.sh"

find: '/usr/share/applications/mimeinfo.cache': No such file or directory
2017/06/10 09:38:03 abnormal exit: exit code=1
2017/06/10 09:38:03 running: F:\cygwin64\bin\bash.exe --norc --noprofile 
"/etc/postinstall/zp_fontconfig_cache_1.sh"
2017/06/10 09:38:19 running: F:\cygwin64\bin\bash.exe --norc --noprofile 
"/etc/postinstall/zp_glib2.0.sh"
2017/06/10 09:38:20 running: F:\cygwin64\bin\bash.exe --norc --noprofile 
"/etc/postinstall/zp_man-db.sh"
2017/06/10 09:38:20 running: F:\cygwin64\bin\bash.exe --norc --noprofile 
"/etc/postinstall/zp_shared-mime-info.sh"

2017/06/10 09:38:20 abnormal exit: exit code=127


--
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: Use of SHELL env var by login

[Ernie Rael]

On 9/27/2016 3:58 AM, Andrew Schulman wrote:

I just moved the cygwin installation. The "last" peculiarity I ran into
was that the login shell, with the shortcut "F:\cygwin64\bin\mintty.exe
-i /Cygwin-Terminal.ico -", a ps showed

  /cygdrive/c/cygwin64/bin/bash

instead of /usr/bin/bash

I tracked this down the the windows setting for SHELL, the one you get
to from windows' SystemProperties dialog, which was
C:/cygwin64/bin/bash. The /etc/passwd file specifies /bin/bash.

Is this expected behavior? (Though I can see why SHELL is there and I'd
need to change it)

/etc/passwd is deprecated. Since Cygwin 2.5 IIRC, Cygwin no longer looks for it,
getting information about users directly from the operating system instead.


Not exactly. IIUC /etc/passwd is *not* deprecated. /etc/passwd is used 
if "passwd: files" is in /etc/nsswitch.conf. But I'll be studying about 
all this in detail very soon.


In any event, one of the reasons I'm moving the cygwin installation is 
so that I have a copy. I'm making sure I know how to switch between 
installations. I'm finally upgrading my installation from 1.7 (ancient, 
before SAM/AD and new permissions) and I want to be able to go back 
temporarily if things don't go smoothly.


The only reason I started this thread, is that it seems wrong that 
$SHELL is used to specify the login shell. AFAIK, it should come from 
passwd, or (according to my reading of cygwin docs) from one of the 
methods specified by /etc/nsswitch.conf in modern cygwin releases. When 
I upgrade, I guess I'll find out.



Unless you have a special need for it, you should remove it. Same for
/etc/group.

In the absence of /etc/passwd, setting SHELL is the right way to set your login
shell.

Andrew


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






--
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: Use of SHELL env var by login

[Ernie Rael]

On 9/26/2016 7:18 PM, Linda Walsh wrote:

Ernie Rael wrote:
I just moved the cygwin installation. The "last" peculiarity I ran 
into was that the login shell, with the shortcut 
"F:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -", a ps showed


/cygdrive/c/cygwin64/bin/bash

instead of /usr/bin/bash

I tracked this down the the windows setting for SHELL, the one you 
get to from windows' SystemProperties dialog, which was 
C:/cygwin64/bin/bash. The /etc/passwd file specifies /bin/bash.


I don't think cygwin sets the Windows SHELL variable in the
registry.  My SHELL value in the System section is 'C:/Bin/Bash.exe', 
which isn't a cygwin-looking path (looks like something I set). Are you

sure you didn't set it in the past sometime?


I suppose I might have set it way back when, but I do wonder why I would 
have. It's interesting that you also have it set; there must be 
something somewhere that prompted its setting. I can't find anything 
online that suggests that cygwin would have set it.


In any event, I still wonder why mintty/login use that rather than 
/etc/passwd.






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






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

Use of SHELL env var by login

[Ernie Rael]

I just moved the cygwin installation. The "last" peculiarity I ran into 
was that the login shell, with the shortcut "F:\cygwin64\bin\mintty.exe 
-i /Cygwin-Terminal.ico -", a ps showed


/cygdrive/c/cygwin64/bin/bash

instead of /usr/bin/bash

I tracked this down the the windows setting for SHELL, the one you get 
to from windows' SystemProperties dialog, which was 
C:/cygwin64/bin/bash. The /etc/passwd file specifies /bin/bash.


Is this expected behavior? (Though I can see why SHELL is there and I'd 
need to change it)



--
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: Setting up cygrunsrv after moving installation to another drive

[Ernie Rael]

Thanks Brian, the Windows command to manipulate service configuration is 
exactly what I needed.

-ernie

On 9/25/2016 6:17 PM, Brian Inglis wrote:

On 2016-09-25 17:28, Ernie Rael wrote:
I have just moved (robocopy) cygwin installation from C:/cygwin64 to 
F:/cygwin64 (win7). My stumbling block is handling cygrunsrv.


For cygrunsrv, I thought I could change the service properties to 
start it from F:/..., but I can't figure out how to do that on Win7.


Any suggestions on how best to get cygrunsrv going/installed after 
moving cygwin installation?


$ sc qc cygserver
will show how the service is currently configured e.g.

[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: cygserver
TYPE   : 10  WIN32_OWN_PROCESS
START_TYPE : 2   AUTO_START  (DELAYED)
ERROR_CONTROL  : 1   NORMAL
BINARY_PATH_NAME   : C:\cygwin64\bin\cygrunsrv.exe
LOAD_ORDER_GROUP   :
TAG: 0
DISPLAY_NAME   : CYGWIN cygserver
DEPENDENCIES   :
SERVICE_START_NAME : LocalSystem

From an elevated prompt (run as Admin):

$ sc config cygserver binPath= $(cygpath -w $(which cygrunsrv))

or the Windows equivalent from an elevated cmd prompt:


sc config cygserver binPath= F:\cygwin64\bin\cygrunsrv.exe


IIRC the space after the = is required.




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

Setting up cygrunsrv after moving installation to another drive

[Ernie Rael]

I have just moved (robocopy) cygwin installation from C:/cygwin64 to 
F:/cygwin64 (win7). My stumbling block is handling cygrunsrv.


For cygrunsrv, I thought I could change the service properties to start 
it from F:/..., but I can't figure out how to do that on Win7.


Any suggestions on how best to get cygrunsrv going/installed after 
moving cygwin installation?


-ernie


--
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: moving Cygwin64 to another drive

[Ernie Rael]

Thanks Marco, the -zb option to robocopy did the trick. (Now for the 
next issues...)


-ernie

On 9/23/2016 9:59 PM, Marco Atzeri wrote:

On 24/09/2016 03:26, Ernie Rael wrote:

On 9/23/2016 4:28 PM, Brian Inglis wrote:

On 2016-09-23 17:11, Ernie Rael wrote:

I found a thread, https://cygwin.com/ml/cygwin/2015-04/msg8.html,
from last year where Corinna suggests the following (which works for
her; she notes YMMV)
robocopy C:\cygwin64 F:\cygwin64 /e /purge /z /copyall /sl




Run robocopy as admin from an elevated command shell (bash or cmd)
with Administrator privileges.


Simply running as admin doesn't solve the problem.

$ robocopy C:/cygwin64 F:/cygwin64 -e -purge -z -copyall -sl


100%New File 210shells
100%New File1595ssh_config
New File 668 ssh_host_dsa_key
2016/09/23 18:06:38 ERROR 5 (0x0005) Copying File
C:\cygwin64\etc\ssh_host_dsa_key
Access is denied.
Waiting 30 seconds...

ADMIN erra@spirit ~
$ id
uid=1000(erra) gid=513(None)
groups=513(None),544(Administrators),545(Users),1007(HomeOffice)



try with options
   /ZB :: use restartable mode; if access denied use Backup mode.

Regards
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






--
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: moving Cygwin64 to another drive

[Ernie Rael]

On 9/23/2016 7:06 PM, Brian Inglis wrote:

On 2016-09-23 19:26, Ernie Rael wrote:

On 9/23/2016 4:28 PM, Brian Inglis wrote:

On 2016-09-23 17:11, Ernie Rael wrote:

I found a thread, https://cygwin.com/ml/cygwin/2015-04/msg8.html,
from last year where Corinna suggests the following (which works 
for her; she notes YMMV)

robocopy C:\cygwin64 F:\cygwin64 /e /purge /z /copyall /sl
On Win7, I'm on a old cygwin installation (thought I'd copy to more 
spacious disk before updating) I tried this command after ssh to an 
admin account, but the command terminates with

100%New File 210shells
100%New File1595 ssh_config
New File 668 ssh_host_dsa_key
2016/09/23 14:54:53 ERROR 5 (0x0005) Copying File 
C:\cygwin64\etc\ssh_host_dsa_key

Access is denied.
where
$ ls -l ssh_host_dsa_key
-rw--- 1 cyg_server Administrators 668 Apr 20  2014 
ssh_host_dsa_key

I don't know much about windows. Any ideas on how to get this to work?


Run robocopy as admin from an elevated command shell (bash or cmd) 
with Administrator privileges.



Simply running as admin doesn't solve the problem.

$ robocopy C:/cygwin64 F:/cygwin64 -e -purge -z -copyall -sl


100%New File 210shells
100%New File1595ssh_config
New File 668 ssh_host_dsa_key
2016/09/23 18:06:38 ERROR 5 (0x0005) Copying File 
C:\cygwin64\etc\ssh_host_dsa_key

Access is denied.
Waiting 30 seconds...

ADMIN erra@spirit ~
$ id
uid=1000(erra) gid=513(None) 
groups=513(None),544(Administrators),545(Users),1007(HomeOffice)


Try from elevated Command Prompt (Admin) with expected path delimiters 
and switch chars:

> robocopy C:\cygwin64 F:\cygwin64 /e /purge /z /copyall /sl
I've had success with:
... /s /copyall /xj /sl /mt:8 /r:0 /w:0 /ndl /nfl /np
but YMMV


Note the 'ls' command output. The cyg_server is a very special account.


--
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: moving Cygwin64 to another drive

[Ernie Rael]

On 9/23/2016 7:06 PM, Brian Inglis wrote:

On 2016-09-23 19:26, Ernie Rael wrote:

On 9/23/2016 4:28 PM, Brian Inglis wrote:

On 2016-09-23 17:11, Ernie Rael wrote:

I found a thread, https://cygwin.com/ml/cygwin/2015-04/msg8.html,
from last year where Corinna suggests the following (which works 
for her; she notes YMMV)

robocopy C:\cygwin64 F:\cygwin64 /e /purge /z /copyall /sl
On Win7, I'm on a old cygwin installation (thought I'd copy to more 
spacious disk before updating) I tried this command after ssh to an 
admin account, but the command terminates with

100%New File 210shells
100%New File1595 ssh_config
New File 668 ssh_host_dsa_key
2016/09/23 14:54:53 ERROR 5 (0x0005) Copying File 
C:\cygwin64\etc\ssh_host_dsa_key

Access is denied.
where
$ ls -l ssh_host_dsa_key
-rw--- 1 cyg_server Administrators 668 Apr 20  2014 
ssh_host_dsa_key

I don't know much about windows. Any ideas on how to get this to work?


Run robocopy as admin from an elevated command shell (bash or cmd) 
with Administrator privileges.



Simply running as admin doesn't solve the problem.

$ robocopy C:/cygwin64 F:/cygwin64 -e -purge -z -copyall -sl


100%New File 210shells
100%New File1595ssh_config
New File 668 ssh_host_dsa_key
2016/09/23 18:06:38 ERROR 5 (0x0005) Copying File 
C:\cygwin64\etc\ssh_host_dsa_key

Access is denied.
Waiting 30 seconds...

ADMIN erra@spirit ~
$ id
uid=1000(erra) gid=513(None) 
groups=513(None),544(Administrators),545(Users),1007(HomeOffice)


Try from elevated Command Prompt (Admin) with expected path delimiters 
and switch chars:

> robocopy C:\cygwin64 F:\cygwin64 /e /purge /z /copyall /sl
I've had success with:
... /s /copyall /xj /sl /mt:8 /r:0 /w:0 /ndl /nfl /np
but YMMV


It is elevated, AFAICT. That's the ",544(Administrators),..." in the 
id command output. BTW, Robocopy seems to accept shellish syntax (saw a 
note in some docs) and have tried both ways.


-ernie


--
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: moving Cygwin64 to another drive

[Ernie Rael]

On 9/23/2016 4:28 PM, Brian Inglis wrote:

On 2016-09-23 17:11, Ernie Rael wrote:

I found a thread, https://cygwin.com/ml/cygwin/2015-04/msg8.html,
from last year where Corinna suggests the following (which works for 
her; she notes YMMV)

robocopy C:\cygwin64 F:\cygwin64 /e /purge /z /copyall /sl
On Win7, I'm on a old cygwin installation (thought I'd copy to more 
spacious disk before updating) I tried this command after ssh to an 
admin account, but the command terminates with

100%New File 210shells
100%New File1595ssh_config
New File 668 ssh_host_dsa_key
2016/09/23 14:54:53 ERROR 5 (0x0005) Copying File 
C:\cygwin64\etc\ssh_host_dsa_key

Access is denied.
where
$ ls -l ssh_host_dsa_key
-rw--- 1 cyg_server Administrators 668 Apr 20  2014 
ssh_host_dsa_key

I don't know much about windows. Any ideas on how to get this to work?


Run robocopy as admin from an elevated command shell (bash or cmd) 
with Administrator privileges.



Simply running as admin doesn't solve the problem.

$ robocopy C:/cygwin64 F:/cygwin64 -e -purge -z -copyall -sl


100%New File 210shells
100%New File1595ssh_config
New File 668 ssh_host_dsa_key
2016/09/23 18:06:38 ERROR 5 (0x0005) Copying File 
C:\cygwin64\etc\ssh_host_dsa_key

Access is denied.
Waiting 30 seconds...

ADMIN erra@spirit ~
$ id
uid=1000(erra) gid=513(None) 
groups=513(None),544(Administrators),545(Users),1007(HomeOffice)



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

moving Cygwin64 to another drive

[Ernie Rael]

Greetings,

I found a thread, https://cygwin.com/ml/cygwin/2015-04/msg8.html, 
from last year where Corinna suggests the following (which works for 
her; she notes YMMV)


robocopy C:\cygwin64 F:\cygwin64 /e /purge /z /copyall /sl

On Win7, I'm on a old cygwin installation (thought I'd copy to more 
spacious disk before updating) I tried this command after ssh to an 
admin account, but the command terminates with


100%New File 210shells
100%New File1595ssh_config
New File 668 ssh_host_dsa_key
2016/09/23 14:54:53 ERROR 5 (0x0005) Copying File 
C:\cygwin64\etc\ssh_host_dsa_key

Access is denied.

where

$ ls -l ssh_host_dsa_key
-rw--- 1 cyg_server Administrators 668 Apr 20  2014 
ssh_host_dsa_key



I don't know much about windows. Any ideas on how to get this to work?

-ernie


--
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: git and absolute Windows-style paths

[Ernie Rael]

On 4/20/2016 1:37 PM, Eliot Moss wrote:

I think this will do it:

function git {
  declare -a ARGS
  for n in "$@" ; do ARGS+=("$(cygpath -u -- "${n}")") ; done
  command git "${ARGS[@]}"
}

The reason this is a little more complicated than some other approaches
might be is that it will also work for arguments that have space, e.g.,

git add "C:/My Documents/foo.doc"


Notice that
   IFS=$'\n'; args=($(cygpath -m -- "$@")); IFS=$' \t\n'
also handles arguments with spaces. You don't need the shell for loop.

-ernie


Regards -- Eliot

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






--
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: pthread_attr_init() returning errors

[Ernie Rael]

On 4/20/2016 10:22 AM, Canham, Timothy K (348C) wrote:

I think I understand what happened now. The call to pthread_attr_init() is 
contained within a function we use to start threads. It is called successive 
times and it fails on the second call. It would appear that the stack entry 
gets laid out the exact same way as the previous call, so pthread_attr_init() 
sees the previous pthread_attr_t. I added a memset() of att and the issue went 
away. It looks like that is a good practice anyway.


Best practice might be using pthread_attr_destroy(attr).



I would be interested in checking out the dev releases, but I don't want to 
mess with my working Cygwin install.

Tim Canham
JPL Flight Software

-Original Message-
From: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com]
Sent: Wednesday, April 20, 2016 7:40 AM
To: cygwin@cygwin.com
Cc: Canham, Timothy K (348C) 
Subject: Re: pthread_attr_init() returning errors

On Apr 20 14:20, Canham, Timothy K (348C) wrote:

From: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com]
On Apr 19 19:49, Canham, Timothy K (348C) wrote:

I have some code to start a task that suddenly started failing.
This is pretty mature code. Here is the code fragment with my added
printf()

 pthread_attr_t att;
 int stat = pthread_attr_init();
 if (stat != 0) {
 printf("pthread_attr_init: (%d)(%d): 
%s\n",stat,errno,strerror(stat));
 // return
 }

Here is the output:

pthread_attr_init: (16)(0): Device or resource busy

This is most unusual.  What happens is this:

A pthread_attr_t is a pointer to a pointer to a struct with a magic
number.  And at the start of pthread_attr_init this magic number is
tested if it's already the magic number expected for an object of
type pthread_attr_t.  And only if so, the pthread_attr_init function
fails with EBUSY.

That means, the arbitrary value in the uninitialized att prior to the
call to pthread_attr_init is a pointer value which points to valid
memory which has the magic value 0xdf0df048.  Wow.

This means we can't keep up with the tests in the pthread_FOO_init
functions since they could point to an *supposedly* initialized
object, while in fact the value they point to is only accidentally so
that it looks like an initialized object.

I provided new developer snapshots on https://cygwin.com/snapshots/
and I've just uploaded a 2.5.1-0.1 test release which you can install
via setup as soon as your mirror has catched up.

Pleaser give any of them a try.

So what you are saying is that when pthread_attr_init() checked for
the magic number in supposedly uninitialized memory it found the exact
value of the magic number? That seems highly suspect. Seems like it
may be pointing to a valid previous entry.

That may be the case.  But in your example, pthread_attr_t att is very 
certainly uninitialized, being an uninitialized auto variable.  So, if it 
actually points to an already initialized pthread_addr_t, it does so by 
accident, because the stack slot it was previously used by another, initialized 
pthread_addr_t.  Therefore the check in pthread_attr_init is spurious.  
Apparently there's a chance, albeit slim, that it returns EBUSY due to a false 
positive.

POSIX says:

   Results are undefined if pthread_attr_init() is called specifying an
   already initialized attr attributes object.

And neither is EBUSY defined as a valid return value, nor are such checks 
performed in glibc.  So I dropped the checks now in Cygwin as well.

So, please give a dev snapshot or the 2.5.1-0.1 test release a try.


Thanks,
Corinna




--
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: git and absolute Windows-style paths

[Ernie Rael]

On 4/20/2016 9:10 AM, Brian Clifton wrote:

I agree completely-

Faking out git by wrapping it as a function in your .bashrc would be an ideal 
approach.  I was the person championing that PR which got rejected, 
unfortunately. The NPM folks were recommending to use mingw which *is* 
supported... but I haven't seen any updates to that project since 2013... and I 
prefer the approach Cygwin takes :)

Eliot, I would be all about taking you up on fixing that psuedo-code example I 
shared earlier. I have a lot to learn about shell scripting and while I am sure 
I can figure it out, having help would be extremely appreciated :)

The example I shared in my intro thread:
#
function git {
 for var in "$@"
 do
 if [[ $var == *":\\"* ]]; then
 $var="$(cygpath $var)" #this doesn't work, but the idea is to do 
something like this
 fi
 done
 command git "$@"
}
#


This extract from a bash function, using an array assignment, might be 
of interest.


  IFS=$'\n'
  args=($(cygpath -m -- "$@"))
  IFS=$' \t\n'
  gvim "${args[@]}"



From: cygwin-ow...@cygwin.com  on behalf of Eliot Moss 

Sent: Wednesday, April 20, 2016 8:52 AM
To: cygwin@cygwin.com
Subject: Re: git and absolute Windows-style paths

On 4/20/2016 11:44 AM, silverwind wrote:

Hey,


Does it work if you do:

git add c:/test/file

Nope, won't work either. No file is added, exit code 0 is given.

  > I can't immediately see what's going wrong, so I'm going to report this 
upstream.

Thanks. I came upon this issue through npm which is using these Windows paths 
for certain git
operations. Unfortunately, The npm team is very reluctant when it comes to 
merging Cygwin-specific
patches, so chances of landing a fix on their side are rather slim.

Is there a public repository for the git package used by Cygwin?

I think that tackling this with a script/function is a better approach ...

Eliot Moss

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


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






--
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: How to expand tabs? Where is expand program.

[Ernie Rael]

I hit RETURN too quickly...

There's also vim's :retab command.

-ernie

On 7/2/2015 4:14 PM, Richard Heintze wrote:

There used to be a very handy cygwin program called expand for expanding tabs 
into spaces.

Now I cannot find it on the nice installation GUI (setup_x86_64.exe).

I tried searching the archives for it but there were too many hits for other topics 
(expand is a common word, apparently).

Has this been superseded by a better program?
Has it been taken away? I hope not!

How can I get a command line interface for expanding tabs into spaces that I 
can easily use from VI?
Thanks
Siegfried

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






--
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: How to expand tabs? Where is expand program.

[Ernie Rael]

On 7/2/2015 4:14 PM, Richard Heintze wrote:

There used to be a very handy cygwin program called expand for expanding tabs 
into spaces.

Now I cannot find it on the nice installation GUI (setup_x86_64.exe).

$ cygcheck -f /usr/bin/expand.exe
coreutils-8.15-3

Probably out of date, but I'd guess is still available.

-ernie


I tried searching the archives for it but there were too many hits for other topics 
(expand is a common word, apparently).

Has this been superseded by a better program?
Has it been taken away? I hope not!

How can I get a command line interface for expanding tabs into spaces that I 
can easily use from VI?
Thanks
Siegfried

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






--
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: Problem passing file names with embedded space to Windows executable via bash function

[Ernie Rael]

On 6/26/2015 12:06 PM, JJ Ottusch wrote:

I am trying to define a function in my '.bash_profile' that takes a file or
list of files as an argument and passes the list to a Windows executable
after converting all the filenames to full path filenames with 'cygpath'.


I use something similar to this, perhaps it would meet your needs. You 
may want to use different option to cygpath.


   #!/usr/bin/bash

   targs() {
if (($# == 0)); then
args=()
else
IFS=$'\n'
args=($(cygpath -m -- $@))
IFS=$' \t\n'
fi

for i in ${args[@]}; do echo '$i'; done

some_command ${args[@]}
   }


-ernie



The whole point of the function is to use 'cygpath' to put the filenames in a
Windows compatible format for me so I don't have to do it every time I call
the Windows executable from a CYGWIN term.

My function works fine except in cases where any part of the path or filename
contains a space. In that case the list of arguments the Windows executable
sees is incorrectly broken apart by the embedded spaces. I can verify this by
looking at argc.


Here are some examples with comments. All commands run from
'/cygdrive/c/Temp/Part1\ Part2/' in a CYGWIN RXVT term.


Let the windows executable be named 'oglv64' and start with the usual
int main(int argc, char** argv)
Let there be two files it can take as arguments named 'file1' and 'file2' in
the directory '/cygdrive/c/Temp/Part1 Part2', where 'Part1 Part2' is a
subdirectory name with an embedded space. Let the defined function be named
'foo'.


1. Show the files

$ dir /cygdrive/c/Temp/Part1\ Part2/
file1*  file2*

2. Test the function with 'echo' instead of 'oglv64'. 'cygpath' works
correctly on each file, but there is a bare space between 'Part1' and 'Part2'
which can be expected to cause problems with 'oglv64'.

$ foo() { echo `cygpath -am $@` ; }; foo file*
C:/Temp/Part1 Part2/file1 C:/Temp/Part1 Part2/file2

3. So, escape the space. Looks good.

$ foo() { echo `cygpath -am $@ | sed 's/ /\\\ /'` ; }; foo file*
C:/Temp/Part1\ Part2/file1 C:/Temp/Part1\ Part2/file2

4. Although I can't show it, the Window executable works exactly as desired
when given the above line as its input. argc=3 and 'oglv64' operates on the
two files as desired.

$ oglv64 C:/Temp/Part1\ Part2/file1 C:/Temp/Part1\ Part2/file2

5. Now try this inside the function definition. As shown below, this didn't
work. argc=5 instead of 3.

$ foo() { oglv64 `cygpath -am $@ | sed 's/ /\\\ /'` ; }; foo file*
Can't load C:/Temp/Part1\.
Can't load Part2/file1.
Can't load C:/Temp/Part1\.
Can't load Part2/file2.

6. Put the full argument in quotes and try again. The 'echo' result is
correct, but given on two separate lines. However, the Windows executable
sees argc=2 and thinks it's all one long filename. Wrong, as expected.

$ foo() { echo `cygpath -am \$@\ | sed 's/ /\\\ /'` ; }; foo file*
C:/Temp/Part1\ Part2/file1
C:/Temp/Part1\ Part2/file2

$ foo() { oglv64 `cygpath -am \$@\ | sed 's/ /\\\ /'` ; }; foo file*
Can't load C:/Temp/Part1\ Part2/file1
C:/Temp/Part1\ Part2/file2.

7. Drop the escaped space and try forcing quotes at the end of each 'cygpath'
result. Looks fine with 'echo', but the Windows executable still sees argc=5
rather than argc=3.

$ foo() { echo `cygpath -am $@ | sed 's/^/\/;s/$/\/'` ; }; foo file*
C:/Temp/Part1 Part2/file1 C:/Temp/Part1 Part2/file2

$ foo() { oglv64 `cygpath -am $@ | sed 's/^/\/;s/$/\/'` ; }; foo file*
Can't load C:/Temp/Part1.
Can't load Part2/file1.
Can't load C:/Temp/Part1.
Can't load Part2/file2.

8 On the other hand, using the output from 'echo' as a direct argument to
'oglv64' works fine.

$ oglv64 C:/Temp/Part1 Part2/file1 C:/Temp/Part1 Part2/file2


No success so far. I am looking to find a simple solution to this problem
(other than eliminating spaces from all file/directory names). It would have
multiple applications.

jjo


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






--
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: Problem passing file names with embedded space to Windows executable via bash function

[Ernie Rael]

On 6/26/2015 2:27 PM, ncokwq...@sneakemail.com wrote:

[ This is meant to be a reply to the response post by Ernie Rael, which I 
managed to lose so there is no referencing. ]

On 6/26/2015 12:50 PM, Ernie Rael wrote:


I use something similar to this, perhaps it would meet your needs. You may want to 
use different option to cygpath.

   #!/usr/bin/bash

   targs() {
if (($# == 0)); then

 _ _

args=()
else
IFS=$'\n'

  _

args=($(cygpath -m -- $@))

   ___   __ __

IFS=$' \t\n'

  _

fi

for i in ${args[@]}; do echo '$i'; done

some_command ${args[@]}

  ___

   }


-ernie

I modified Ernie's solution for my purposes and it works beautifully. Thanks so 
much.

The key point seems to be the temporary redefinition of IFS.

However, Ernie's solution also incorporates other features / syntactical 
elements of bash that I would never have thought to use and I'm interested to 
know if they are necessary and what they do. They are underlined in the message 
above.


IMHO you are best served by looking up the stuff in the bash 
documentation; that's a good way to learn new stuff when exploring 
example code. Do man bash, search and enjoy; you can search with REs. 
But here's some hints.


To handle a list of files, bash arrays are convenient.


Basically,
1. Why the '((  ))' syntax with 'if'? Same as '[  ]'?

arithmetic - search for ((: /\(\(

2. Why precede the white space characters with '$'?

that's $'stuff' search: /\$'

3. Why enclose the 'cygpath' command by '($( ... ))'?

that's two things:
$() - search: /\$\(  (but skip past the $(()
and xxx=() search: /=\(
The $() construct replaces the ancient `` syntax, xxx=() is for arrays

4. What does '--' do for 'cygpath'?
The '--' is not cygpath specific. Try man getopt. Note the difference 
between entering

cygpath -- -m and cygpath -m

5. Why 'args[@]' rather than just 'args'?
Check this out under Arrays in the docs. just $args is the first 
element of the array.

Definitely want @ not *


Anyway, thanks for the simple solution to my problem. If I learn some more 
about obscure bash syntax that will be a bonus.

jjo


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






--
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: [TESTERS needed] New POSIX permission handling

[Ernie Rael]

I'm primarily a lurker, reading this list hoping things soak in a bit. 
So I may be off base on this.


In the table below, describing NULL DENY access mask, looks like 
there's a typo concerning read/execute. (of course it might just be a 
windows mapping peculiarity that I really didn't want to know about ;-)


-ernie

On 4/11/2015 3:07 AM, Corinna Vinschen wrote:

On Apr 11 11:40, Corinna Vinschen wrote:

On Apr 10 19:00, Steven Penny wrote:

On Fri, Apr 10, 2015 at 5:07 AM, Corinna Vinschen wrote:

Please give the new code a try.  I uploaded new 2015-04-10 developer
snapshots to https://cygwin.com/snapshots/

Here is the test I ran:

 $ cd /cygdrive/c

 $ touch ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh

 $ chmod +x ~/bravo.sh ~+/delta.sh

 $ ls -l --color ~/{alpha,bravo}.sh ~+/{charlie,delta}.sh
 -rw-rw-r--+ 1 John None 0 Apr 10 16:51 /cygdrive/c/charlie.sh
 -rwxrwxr-x+ 1 John None 0 Apr 10 16:51 /cygdrive/c/delta.sh(green)
 -rw-r--r--  1 John None 0 Apr 10 16:51 /home/John/alpha.sh
 -rwxrwxr-x  1 John None 0 Apr 10 16:51 /home/John/bravo.sh (green)

So charlie.sh looks strange because it has that extra write permission.
However this is not a big deal for me. My concern was that everything was
showing up executable (green) when running ls --color. So overall this is an
improvement, thanks.

What is '~+'?  Is that some weird bash feature?

Did you check the ACL?  The ACL before and after the change should
explain what happened.  Check it with getfacl *and* icacls to get
an idea what it looks like, and compare the result with the POSIX
ACL rules, as outlined on, e.g., http://linux.die.net/man/5/acl.

On second thought, what you need to know is what the NULL DENY ACE looks
like when looking at it in icacls.

The following bits in the NULL DENY access mask are used:

   Windows access-   POSIX access
   --  
   FILE_READ_DATA  S_ISVTX
   FILE_WRITE_DATA S_ISGID
   FILE_APPEND_DATAS_ISUID

   FILE_READ_EAMASK S_IXOTH  (POSIX execute perms)
   FILE_WRITE_EA   MASK S_IWOTH  (POSIX write perms)
   FILE_EXECUTEMASK S_IROTH  (POSIX read perms)


Are read and execute swapped intentionally in the above?



   FILE_DELETE_CHILD   Set if MASK is valid

   READ_CONTROLSet to mark this as a new style ACL.

   SYNCHRONIZE Has no meaning, but icacls has a bug in
   printing the access mask of DENY ACEs.

Same bits are used in the inheritable NULL DENY, but S_ISVTX and S_ISUID
should never be set, because they are not supposed to be inherited,


HTH,
Corinna




--
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: Change PS1 when running as administrator

[Ernie Rael]

On 6/17/2014 1:45 AM, GrahamC wrote:

If we are looking for other alternatives the GROUPS environment variable can 
also be used:

PS1='\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
for G in ${GROUPS[@]}; do
 if [ $G = 544 ]; then
 PS1='\[\e]0;Administrator \w\a\]\n\[\e[32m\]\u@\h 
\[\e[33m\]\w\[\e[0m\]\n# '
 fi
done


Speaking of alternatives,

For matching in bash, something like

[[ $(id -G) =~ \b544\b ]]

was suggested (the suggestion used symbolic name instead of a number and
didn't use word boundary). Seems like word boundary is needed, but I
couldn't get this to work. Are the regex boundary matchers not
supported  by bash =~ operator?  Can use something like

id -G | grep -q \b544\b

(or echo ${GROUPS[@]} | ...)

 -ernie



--
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: Change PS1 when running as administrator

[Ernie Rael]

On 6/17/2014 9:34 AM, Andrey Repin wrote:


  [[ $(id -G) =~ \b544\b ]]
was suggested (the suggestion used symbolic name instead of a number and
didn't use word boundary). Seems like word boundary is needed, but I
couldn't get this to work. Are the regex boundary matchers not
supported  by bash =~ operator?

I don't think bash equivalent of test implements Perl RE.
Neither the base test implementation, to that extent.


I thought, perhaps incorrectly, that \b has been around forever and is 
posix.


In any event, looks like

[[ $(id -G) =~ (^| )544($| ) ]]

would work.

--
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: interactive hg (mercurial) using ssh is getting authentication failures to sourceforge

[Ernie Rael]

On 5/12/2014 4:20 AM, Andrey Repin wrote:

Greetings, Ernie Rael!


At the end of this post, there is experimental evidence that the ssh is
disasociated from the tty in the when spawned by hg.
NOTE: hg is a Win7 command, not compiled with the cygwin dll.

Don't you see anything suspicious here?

Right you are. After I posted, I realized I hadn't clearly stated my 
questions. This could be something about my setup, but... I've only just 
joined this mailing list; I don't have an historical perspective.


Is this expected behavior? If so, any idea what changed over the last 6 
- 9 months? Was this a conscious change in behavior?


I'd been using this setup for years; the old behavior, which gives a 
higher degree of interoperability (at least in this case), is certainly 
natural. If the Win program didn't do anything explicit to disassociate 
from the tty, why shouldn't it work? Does windows have a concept of 
controlling tty? Is there something mercurial/python could, as a native 
app, that would get this to work?


I know little about windows' internals. I understand that even though it 
used to work, that it may have been a 'fortunate accident.


-ernie

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