PATH with spaces
Hello all, First of all, let me introduce myself... my name is Jean, but you can call me Sunoki and I am a 26 year old computer scientist from Brazil... I'm running Windows 7 at home and I should have installed some linux distribution, but I have a small personal project and I wondered it would be easier to just work on it using Cygwin... well, I might be wrong... ^_^ I installed it yesterday with the default option including the Perl section... and I'm having a error on the PATH and I believe because windows has spaces on the directories names... let me explain you... my PATH is the following: $ printenv PATH /usr/local/bin:/usr/bin:/bin:/cygdrive/c/Program Files (x86)/PC Connectivity Sol ution/:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/Syst em32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0/:/cygdrive/c/Progr am Files (x86)/ATI Technologies/ATI.ACE/Core-Static:/cygdrive/c/Program Files (x 86)/Microsoft SQL Server/90/Tools/binn/:/cygdrive/c/strawberry/c/bin:/cygdrive/c /strawberry/perl/site/bin:/cygdrive/c/strawberry/perl/bin:/cygdrive/c/Program Fi les (x86)/Common Files/Symbian/tools:/cygdrive/c/Program Files (x86)/CSL Arm Too lchain/bin:/cygdrive/c/strawberry/perl/bin:/cygdrive/c/Program Files (x86)/IDM C omputer Solutions/UltraEdit/:/cygdrive/c/strawberry/perl/bin and when I try to run the make I would like to I have the following error: $ make cygwin warning: MS-DOS style path detected: /usr/local/bin/C:\Program Preferred POSIX equivalent is: /usr/local/bin/C:/Program CYGWIN environment variable option "nodosfilewarning" turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames Can't find C:\Program on PATH. I believe that the "can't find error" is happening because the Cygwin does not understand the "Program Files (x86)" as one thing... it stops after the first space and causes the error. Am I right? How can I fix it? I tried mounting this directory as another one without spaces, I tried to rewrite the PATH enclosing the words with spaces in "". But so far nothing worked. Can you help me, please? Many thanks, Sunoki -- View this message in context: http://old.nabble.com/PATH-with-spaces-tp30799162p30799162.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Cygwin Support for Shadow Copies Exposed As Drives?
On Jan 29 17:21, Leon Vanderploeg wrote:
> References: <002b01cbac64$54079040$fc16b0c0$@vaultnow.com>
With the upcoming 1.7.8 (and recent snapshots, see
http://cygwin.com/snapshots/) you can access volume shadow copies very
easily:
As administrator, elevated on Vista and later:
$ cd /proc/sys/Devices
$ ls -l Harddisk*
drwxrwx--- 1 Administrators SYSTEM 0 Jan 30 12:27 Harddisk0
brwxrwx--x 1 Administrators SYSTEM 0, 242 Jan 30 12:27 HarddiskVolume1
brwxrwx--x 1 Administrators SYSTEM 0, 242 Jan 30 12:27 HarddiskVolume2
brwxrwx--x 1 Administrators SYSTEM 0, 242 Jan 30 12:27 HarddiskVolume3
brwxrwx--x 1 Administrators SYSTEM 0, 242 Jan 30 12:27
HarddiskVolumeShadowCopy3
lr--r--r-- 1 Administrators SYSTEM 0 Jan 30 12:27
HarddiskVolumeShadowCopy{6faf6d91-2259-11e0-9403-000c295ff74f} ->
/proc/sys/Device/HarddiskVolumeShadowCopy3
$ cd HarddiskVolumeShadowCopy3
HarddiskVolumeShadowCopy3: Not a directory
$ cd HarddiskVolumeShadowCopy3/
$ pwd
/proc/sys/Devices/HarddiskVolumeShadowCopy3
$ ls -1
$Recycle.Bin
Documents and Settings
PerfLogs
Program Files
ProgramData
Recovery
System Volume Information
Users
Windows
autoexec.bat
config.sys
cygwin
hiberfil.sys
pagefile.sys
$
Note that you have to use a trailing slash to cd into the root directory
of the drive. The reason is that the name "HarddiskVolumeShadowCopy3"
refers to the block device in the first place. Only by attaching the
trailing slash the system (Windows, not Cygwin!) realizes that you
want to access the drive's root dir. This is not necessary to access
other directories on the drive:
$ cd /proc/sys/Devices/HarddiskVolumeShadowCopy3/cygwin
$ ls -1
Cygwin.bat
Cygwin.ico
Cygwin.tcsh.bat
bin
cygdrive
dev
etc
home
lib
sbin
tmp
usr
var
Due to the layout of the native NT namespace and the extra DOS device
path handling there are a couple of other ways to access the shadow
copies, for instance:
$ cd /proc/sys/GLOBAL\?\?/HarddiskVolumeShadowCopy3/
$ cd /proc/sys/\?\?/global/HarddiskVolumeShadowCopy3/
$ cd //./HarddiskVolumeShadowCopy3/
$ cd //?/HarddiskVolumeShadowCopy3/
$ cd //./GLOBALROOT/Devices/HarddiskVolumeShadowCopy3/
but personally I prefer the access via /proc/sys/Devices. It's the
cleanest and easiest one, IMHO.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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: PATH with spaces
On 1/30/2011 6:34 AM, Sunoki wrote: $ make cygwin warning: MS-DOS style path detected: /usr/local/bin/C:\Program Preferred POSIX equivalent is: /usr/local/bin/C:/Program CYGWIN environment variable option "nodosfilewarning" turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames Can't find C:\Program on PATH. I suppose you will meet reluctance, as it will be difficult to "help" until you have read the advice and formed a clearer idea of what you are trying to do. Yes, the warning comes about in part due to the use of an unquoted path with spaces. The primary purpose of cygwin is not for the use of "native" Windows applications. In case you do want that, a useful possibility is to set up the paths correctly in a command prompt window for the Windows applications, then run the cygwin.bat so as to superimpose the cygwin environment. -- Tim Prince -- 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
Issue with socket SO_REUSEADDR when a client is connected.
I have detected an issue in windows xp with socket SO_REUSEADDR when a
tcp client keeps connected forever.
I don't know if it is a cygwin bug or a problem with microsoft winsock
implementation. I don't know if windows vista or windows 7 has the
same behaviour.
I have a server process that open a socket and binds to a port. After
a while, it closes the socket, re-open and re-bind to it.
In Unix (linux, solaris) the server process can always re-bind after
closing the previous socket, but in cygwin, there are some strange
issues. I have prepared a simplified tcp_server test program, in order
to be able to reproduce error in an easy way.
A) If I bind to wildcard address 0.0.0.0 port , it works
successfully, like Unix:
1) tcp_server binds to 0.0.0.0: and create a thread to
accept connections
2) tcp_server sleep for 10 seconds
3) a client process connect to 127.0.0.1: and keeps
connected forever
4) tcp_server awakes, closes all connections to port
(but client process keeps port connected, in ESTABLISHED state)
5) tcp_server successfully reopens and rebind to 0.0.0.0:
B) If I bind to address 127.0.0.1 port , it fails:
1) tcp_server binds to 127.0.0.1: and create a thread
to accept connections
2) tcp_server sleep for 10 seconds
3) a client process connect to 127.0.0.1: and keeps
connected forever
4) tcp_server awakes, closes all connections to port
(but client process keeps port connected, in ESTABLISHED state)
5) an error "bind(): Address already in use" occurs.
C) If there is no client connection, rebind is always successful.
TEST LOG:
=
A) bind to 0.0.0.0
$ ./tcp_server 0.0.0.0 10
Start main
Opening socket on 0.0.0.0
Main: Creating thread
Start sleep
Starting server thread, executing "accept"
accepted fd 4
End sleep
pthread_cancel
Waiting for server
Server returned "0x"
End main
Start main
Opening socket on 0.0.0.0
Main: Creating thread
Start sleep
Starting server thread, executing "accept"
End sleep
pthread_cancel
Waiting for server
Server returned "0x"
End main
Start main
Opening socket on 0.0.0.0
B) bind to 127.0.0.1
$ ./tcp_server 127.0.0.1 10
Start main
Opening socket on 127.0.0.1
Main: Creating thread
Starting server thread, executing "accept"
Start sleep
accepted fd 4
End sleep
pthread_cancel
Waiting for server
Server returned "0x"
End main
Start main
bind(): Address already in use
Main: Creating thread
Start sleep
Starting server thread, executing "accept"
Accepted failed: Bad file descriptor
Ending thread
End sleep
pthread_cancel
Waiting for server
close = 9 Bad file descriptor
End main
Start main
bind(): Address already in use
I attach to email a tcp_server and tcp_client examples. Execute
"./tcp_server 127.0.0.1 10" in one terminal and "./tcp_client
127.0.0.1 " in other.
A telnet connection to tcp_server is also OK to see the problems.
This problem occurs sometimes in "varnishtest" tool from varnish
cache software.
#include
#include
#include
#include
#include
#include
#include
#include
#include
char* host;
int port;
int seconds;
int sock;
/**
* Listen to port
*/
int
listen_port()
{
int i, ret;
int sd, val;
sd = socket(AF_INET, SOCK_STREAM, 0);
if (sd < 0) {
perror("socket()");
return (-1);
}
val = 1;
if (setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, &val, sizeof val) != 0) {
perror("setsockopt(SO_REUSEADDR, 1)");
(void)close(sd);
return (-1);
}
struct hostent *ptrh;
struct sockaddr_in saddr;
ptrh = gethostbyname(host);
if ( ((char *)ptrh) == NULL ) {
perror("Invalid host");
return (-1);
}
bzero((char *) &saddr, sizeof(saddr));
saddr.sin_family = AF_INET;
saddr.sin_addr.s_addr = htonl(INADDR_ANY);
saddr.sin_port = htons((u_short)port);
memcpy(&saddr.sin_addr, ptrh->h_addr, ptrh->h_length);
if (bind(sd, (struct sockaddr *) &saddr, sizeof(saddr)) < 0)
{
perror("bind()");
(void)close(sd);
return (-1);
}
return (sd);
}
/**
* Server Thread
*/
static void *
server_thread(void *priv)
{
struct vtclog *vl;
int i, j, fd;
struct sockaddr_storage addr_s;
struct sockaddr *addr;
socklen_t l;
charbuf[1000]; /* buffer for string the server sends */
printf("Starting server thread, executing \"accept\"\n");
addr = (void*)&addr_s;
l = sizeof addr_s;
fd = accept(sock, addr, &l);
if (fd < 0)
{
printf( "Accepted failed: %s\n", strerror(errno));
}
else
{
printf( "accepted fd %d\n", fd);
int n;
n = recv(fd, buf, sizeof(buf), 0);
while (n > 0)
{
send(fd, buf, n, 0);
n = recv(fd, buf, sizeof(buf), 0);
}
printf( "shutting fd %d\n", fd);
j = shutdown(fd, SHUT_WR);
if (!((j) ==
Re: [Bug] Named Pipes (FIFO) / Bash
> I'd be grateful for any insights and/or ideas for possible workarounds. Could anybody please comment if there are changes to the whole area of (named) pipes in the upcoming 1.7.8 release? Should I just grab the latest snapshot and try my luck? I don't mind if it's not POSIX compliant if at least consistent synchronization can be achieved that does not depend on the order of consumers and producers connecting to the pipe (like it did on Cygwin 1.6). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: 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: PATH with spaces
On 30/01/2011 12:56, Tim Prince wrote: > On 1/30/2011 6:34 AM, Sunoki wrote: >> >> $ make >> cygwin warning: >>MS-DOS style path detected: /usr/local/bin/C:\Program >>Preferred POSIX equivalent is: /usr/local/bin/C:/Program >>CYGWIN environment variable option "nodosfilewarning" turns off this >> warning. >>Consult the user's guide for more details about POSIX paths: >> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames >> Can't find C:\Program on PATH. > Yes, the warning comes about in part due to the use of an unquoted path > with spaces. Not directly it doesn't. My PATH has spaces in it and everything works just fine. The shell knows to only separate $PATH at colons. That "Can't find" error message doesn't look like anything make itself would output to me, and how did /usr/local/bin get concatenated to C:\Program anyway? (Note that it doesn't have a trailing slash in the path, so something has done this deliberately.) I think the problem is likely to be that the makefile itself is doing some kind of string processing on the PATH, or perhaps that it is being passed on a commandline somewhere unquoted and ending up looking like multiple words to the receiving program. Sunoki, if that isn't enough of a clue to work out what's going wrong, there's a really useful version of make with a source-level debugger built in called 'remake' that you can get from http://bashdb.sourceforge.net/remake/. (Last time I checked, it was a straightforward "configure && make && make install" to build out-of-the-box, so it should be easy to try out if you want.) cheers, DaveK -- 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: [Bug] Named Pipes (FIFO) / Bash
On Sun, Jan 30, 2011 at 04:24:48PM +0100, Achim Gratz wrote: >> I'd be grateful for any insights and/or ideas for possible workarounds. > >Could anybody please comment if there are changes to the whole area of >(named) pipes in the upcoming 1.7.8 release? There are no changes to named pipes in 1.7.8. Unfortunately, they will remain broken in this release. cgf -- 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: PATH with spaces
Sunoki wrote: $ printenv PATH ... :/cygdrive/c/Program Files (x86)/Common Files/Symbian/tools: ... $ make cygwin warning: MS-DOS style path detected: /usr/local/bin/C:\Program Preferred POSIX equivalent is: /usr/local/bin/C:/Program CYGWIN environment variable option "nodosfilewarning" turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames Can't find C:\Program on PATH. My guess: - You have not installed Cygwin's make package - You have the Symbian toolchain in your path. It contains a tool named make.exe Try this: $ type make make is hashed (/cygdrive/c/Program Files (x86)/Common Files/Symbian/tools/make) If you get the result above, my guess is right, so your config is wrong. When you type make, it runs Symbian's one, not Cygwin's one. You should install Cygwin's make package, the you should clean up your path, at least locally: export PATH=/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem -- Vincent Rivière -- 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: Issue with socket SO_REUSEADDR when a client is connected.
On Jan 30 15:31, jdzstz - gmail dot com wrote: > I have detected an issue in windows xp with socket SO_REUSEADDR when a > tcp client keeps connected forever. > > I don't know if it is a cygwin bug or a problem with microsoft winsock > implementation. I don't know if windows vista or windows 7 has the > same behaviour. Thanks for the testcase. I was going to go to great lengths explaining how WinSock has a bug in SO_REUSEADDR behaviour and how Cygwin has a nifty workaround for this, but I got a bad feeling while writing my reply and started a cycle 1. test 2. read MSDN 3. scratch head 4. debug 5. change 6. goto 1 The Cygwin workaround to fix the WinSock SO_REUSEADDR behaviour from back in 2006 was not so nifty after all. I just fixed that in CVS. I'm going to generate a new developer snapshot right now. Should be up in a couple of minutes. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: On "write" command
On 1/29/2011 8:20 AM, Angelo Graziosi wrote: I would ask if on Cygwin I can use the 'write' command: write - send a message to another user $ write USER [ttyname] I remember I have used it some years ago, but not remember if it was on GNU/Linux or Cygwin. I did a research on http://cygwin.com/packages and didn't find it, but perhaps I did the wrong search.. No, that's the correct place to search. If it's not showing up, none of the current packages provide 'write'. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: On "write" command
On 1/29/11 5:20 AM, Angelo Graziosi wrote: > I would ask if on Cygwin I can use the 'write' command: > > write - send a message to another user > > $ write USER [ttyname] > > I remember I have used it some years ago, but not remember if it was on > GNU/Linux or Cygwin. > > I did a research on http://cygwin.com/packages and didn't find it, but > perhaps I did the wrong search.. Even in other Unix environments, write(1) is seldom used these days. Windows *does* provide a way to send a message to other users using the "msg" command or "net send". signature.asc Description: OpenPGP digital signature
RE: libglade error during cygwin installation
> > On Fri, 2011-01-28 at 22:56 +, Joe Crepeau wrote: > >> xmlcatalog -v --noout --add "system" \ > > ? "http://glade.gnome.org/glade-2.0.dtd"; \ > > ? /usr/share/xml/libglade/glade-2.0.dtd \ > > ? /etc/xml/catalog > > add command failed > > Catalogs cleanup > > > > Do you have an /etc/xml/catalog file yet? If not, run: > > xmlcatalog --noout --create /etc/xml/catalog $ xmlcatalog --noout --create /etc/xml/catalog The above command apparently worked, although, the length of "catalog" is zero (not sure if that is what it's supposed to be). $ cd /etc/xml $ ls -l total 0 -rw-r- 1 jcrepeau Domain Users 0 Jan 30 12:05 catalog > > then try the libglade2.0 postinstall again. The fix is already in Ports > git[1] and will > be in the next libxml2 release. I then run the libglade2.0 postinstall and get this $ /etc/postinstall/libglade2.0.sh add command failed Nothing I have done seems to work. If I were to start from scratch with libglade, what would the steps be?
Re: [ANNOUNCEMENT] Updated: OpenSSH-5.7p1-1
Corinna Vinschen wrote: > I've just updated the Cygwin version of OpenSSH to 5.7p1-1. Routine create_host_keys of script ssh-host-config has not been modified to create ECDSA host key files. Perhaps this is intentional, during an intro period? R/ Bruce J -- 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
