Re: Bug Report: Purging Old and Invalid User Names With Spaces
* From: Robert Peaslee
* To: cygwin at cygwin dot com
* Date: Fri, 16 Mar 2007 17:19:18 -0400
* References:
<[EMAIL PROTECTED]>
Thrall, Bryan wrote:
>Yes, WinXP stores your username twice ("Full name" and "User Name") and
>Cygwin uses the "hidden" one ("User Name"), but I'm pretty sure you
>don't have to reinstall XP to change it!
>IIRC, you can change the username from Control Panel->User
>Accounts->Advanced tab->Advanced button->Users->right click on the user
>and select "Rename". You might need to be Administrator to do this,
>though (and it only works for local users, so if you're on a domain, you
>need to contact the domain admin).
There's a slight problem here. I have XP, but I can't see an Advanced
tab in the User Accounts window. It lacks all advanced functionality,
so I use the Computer Management window as described below:
I no longer have XP installed, but found the same can be done in Vista by
opening the
computer management window (Right click on my computer -> manage ), expanding
the
"Local Users and Groups" tree, and clicking on "Users." Then the instructions
are the
same as Bryan's, right click on the user and hit 'rename' to set a new username.
This does change the real username, and the change will take effect in
Cygwin once the password file has been rebuilt using mkpasswd (or
updated by hand). (However, it should be noted that the user's
profile in Documents and Settings is not renamed).
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Bash scripts may misbehave if SHELLOPTS is exported and 'monitor' is enabled
I have noticed that a few scripts misbehave if SHELLOPTS is exported, or defined in the environment before bash is first invoked. (I had set SHELLOPTS=igncr in the system environment - but I've backed this out to avoid the problems). The problems seem to be caused by incorrect signal handling. In particular, the current version of 'man' crashes with a strange message: $ man bash DESCRIPTION Bash is an sh-compatible command language interpreter that executes commands read from the standard input or from a file. Bash also incor- porates useful features from the Korn and C shells (ksh and csh). Bash is intended to be a conformant implementation of the Shell and Utilities portion of the IEEE POSIX specification (IEEE Standard 1003.1). Bash can be configured to be POSIX-conformant by default. : [1]+ Stopped(SIGTTIN)( cd "/usr/share/man" && ( echo ".pl 1100i"; /usr/ bin/cat '/usr/share/man/man1/bash.1'; echo ".\\\""; echo ".pl \n(nlu+10" ) | /us r/bin/tbl | /usr/bin/nroff -Tlatin1 -mandoc | /usr/bin/less -isrR ) Error executing formatting or display command. System command (cd "/usr/share/man" && (echo ".pl 1100i"; /usr/bin/cat '/usr/sha re/man/man1/bash.1'; echo ".\\\""; echo ".pl \n(nlu+10") | /usr/bin/tbl | /usr/b in/nroff -Tlatin1 -mandoc | /usr/bin/less -isrR) exited with status 38144. No manual entry for bash (I tested this on a fresh installation of the Cygwin base packages, so I'm reasonably sure that other people will be able to reproduce it! I've reproduced it on two machines, both running Windows XP Professional. Note that I have to type 'stty sane' to restore normal terminal operation after the bug has occurred.) It turned out that the problem has something to do with the 'monitor' option being enabled. Normally it would be turned off in noninteractive scripts, but if SHELLOPTS is in the environment the setting (turned on by interactive shells) gets propagated to all shells. The bug disappears if: 1. I keep SHELLOPTS out of the environment, or 2. I change /bin/nroff to use /bin/ash instead of /bin/bash, or 3. I disable the monitor option (set +o monitor) before invoking man -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Bash 3.1.9 and 3.2.4: igncr setting not effective for 'source'd files
Unfortunately I have to report that both versions of bash don't implement the igncr setting if commands are read from a sourced file. For example, I have /etc/profile set up to issue shopt -s igncr # as the first line (or set -o igncr; export SHELLOPTS # for version 3.2.4) If I do unix2dos /etc/profile the command source /etc/profile produces a series of error messages, indicating that characters are not being ignored. If I issue the file as a script, e.g. bash /etc/profile there are no errors. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: bash-3.1-9
From: Eric Blake To: cygwin at cygwin dot com Date: Mon, 02 Oct 2006 21:51:04 -0600 Subject: [ANNOUNCEMENT] Updated: bash-3.1-9 Reply-to: cygwin at cygwin dot com Reply-to: The Cygwin Mailing List -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A new release of bash, 3.1-9, is now available, replacing 3.1-8 as the current version. 3.1-6 remains as the previous version. NEWS: = Due to complaints on the mailing list, this version attempts to alleviate some of the pain of people who have difficulties working around \r\n line endings in scripts residing on binary mounts. [snip] Second, this release adds a new shopt, igncr, which dynamically tells bash to ignore all \r in the input file when it is set; however, it defaults to unset. With this shopt, it is possible to make a bash script work on binary mounts even if it has \r\n line endings, by adding the following line as the first non-comment: shopt -s igncr;# [snip] If you want your script to be portable to other platforms or shells that don't understand igncr, you can write it as: (shopt -s igncr) 2>/dev/null && eval 'shopt -s igncr';# Alternatively, you can set the environment variable BASH_ENV to the name of a file containing startup commands for all bash scripts. If the above command is issued in the file, the shopt command will be set before the script is read - and DOS-format scripts will therefore execute correctly without modification. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Sshd: problem with X11 passthru
>* From: Corinna Vinschen >* To: cygwin at cygwin dot com >* Date: Tue, 28 Mar 2006 12:29:40 +0200 > >On Mar 28 10:17, David Picton wrote: > >From: Corinna Vinschen > >On Mar 27 18:55, David Picton wrote: > >> I have encountered a problem with the sshd server when the client > >> specifies X11 passthru i.e. ssh -Y or ssh -X. > >> [snip original bug report] >> Apologies for not making it clear that I was talking about the Cygwin >> port of sshd. >> The bug seems to be specific to the Cygwin version and I've not seen it on other >> systems. > >Well, the problem is this. I just tried it and I can't reproduce it. >Each session gets another display number, starting at 10, as expected. >Maybe this is somehow due to a sshd_config setting which uncovers a >sshd problem? I don't see how this should be related to Cygwin. I still >think this should be a question for a ssh mailing list. > >Corinna For the record, I'd like to say how I resolved the problem - if I can be permitted just one more post on the subject ... I reproduced the bug when I tried installing the current version of sshd on a second XP machine - DISPLAY=:10.0 every time. (The sshd_config was exactly as created by ssh-host-config - except for one change to permit X11 passthru.) Then I tried reverting to an older version of sshd.exe (dated September 2005) and hey presto - the bug was magicked away. So I'm using that version now. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Sshd: problem with X11 passthru
>From: Corinna Vinschen >To: cygwin at cygwin dot com >Date: Tue, 28 Mar 2006 09:37:28 +0200 >On Mar 27 18:55, David Picton wrote: >> I have encountered a problem with the sshd server when the client >> specifies X11 passthru i.e. ssh -Y or ssh -X. >> >> The allocation of virtual displays doesn't work correctly if two or >> more X11-enabled sessions run at the same time. >> >> As I understand it, the server should give each session a unique >> display number under these circumstances: localhost:10.0, >> localhost:11.0, localhost:12.0 etc. >> >> Instead, all the sessions have DISPLAY=localhost:10.0 at the same >> time. This causes a variety of problems - loss of access to the X >> server (due to changed Magic Cookie authorization on the server when a >> new client connects), or the appearance of windows on the wrong server >> (if two different clients connect). >> >> (Note that setting up Magic Cookie authorization on the client machine >> makes no difference to this bug. It prevents the client-side warning >> about 'fake authorization' but it doesn't cure any of the server-side >> problems!) > >I don't see anything Cygwin specific here. You should ask your >question on a mailing list or newsgroup dedicated to OpenSSH. > >Corinna Apologies for not making it clear that I was talking about the Cygwin port of sshd. The bug seems to be specific to the Cygwin version and I've not seen it on other systems. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Sshd: problem with X11 passthru
I have encountered a problem with the sshd server when the client specifies X11 passthru i.e. ssh -Y or ssh -X. The allocation of virtual displays doesn't work correctly if two or more X11-enabled sessions run at the same time. As I understand it, the server should give each session a unique display number under these circumstances: localhost:10.0, localhost:11.0, localhost:12.0 etc. Instead, all the sessions have DISPLAY=localhost:10.0 at the same time. This causes a variety of problems - loss of access to the X server (due to changed Magic Cookie authorization on the server when a new client connects), or the appearance of windows on the wrong server (if two different clients connect). (Note that setting up Magic Cookie authorization on the client machine makes no difference to this bug. It prevents the client-side warning about 'fake authorization' but it doesn't cure any of the server-side problems!) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug: run emacs: fatal error reading the windows environment
>From: Kirk Hilliard >Date: 03 Mar 2006 15:51:21 -0500 > On Mar 3 21:33, Corinna Vinschen wrote: >> Is that a native Windows emacs? A Cygwin emacs shouldn't have any >> problem. > > No, it is the cygwin emacs. > >``run emacs'' fails with > 12 [main] emacs 900 C:\cygwin\bin\emacs.exe: *** fatal error - > internal error reading the windows environment -- > too many environment variables? > but when run as ``emacs'' from an xterm it works fine. What I first > noticed is that it fails silently when launched from a shortcut that > calls ``run emacs'', so I tried that from the xterm to see what was > going on. > > I will be surprised if I turn out to be the only one this affects, as > it occurs on two separate machines, one upgraded, the other > re-installed fresh. (Perhaps not so many people launch emacs from a > shortcut.) > > Kirk I also see the problem. Emacs fails as described - it would appear that there is a bug in the routine which converts the Windows environment to the Cygwin environment. As a temporary workaround, I changed the icon command to the following: D:\cygwin\bin\run.exe -p /usr/bin:/usr/X11R6/bin bash -c 'emacs -display 127.0.0.1:0.0' This works OK. It would appear that emacs is happy if it is started by a Cygwin process - presumably it doesn't need to read the Windows environment in this case but simply inherits the Cygwin environment from its parent process. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: strange cygstart bug with current Cygwin versions
On 2/3/06, Igor Peshansky <[EMAIL PROTECTED]> wrote: > On Fri, 3 Feb 2006, David Picton wrote: > > > I have encountered a strange bug when starting Microsoft Word when it is > > started by the cygstart command, e.g. "cygstart Index.doc", with the > > current version of the Cygwin dll. > > > > The symptoms are as follows: [snip] > > 3. Attempting to save the file gets no response. The only way to close > > the window is to exit without saving! I have now tested 'cygstart cmd' on the three computers I use, and in every case I see the same problem with the TEMP and TMP environment variables - they retain the Cygwin pathname (regardless of whether this actually causes a problem with Word). For now, I've caused TEMP and TMP to be set to a Windows pathname within Cygwin. I don't see the bug if I run an older version of Cygwin (pre-2006 versions of the Cygwin DLL). TEMP and TMP used to be translated correctly in processes invoked by cygstart. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: strange cygstart bug with current Cygwin versions
On 2/3/06, Igor Peshansky <[EMAIL PROTECTED]> wrote: > On Fri, 3 Feb 2006, David Picton wrote: > > > I have encountered a strange bug when starting Microsoft Word when it is > > started by the cygstart command, e.g. "cygstart Index.doc", with the > > current version of the Cygwin dll. > > > > The symptoms are as follows: > > > > 1. Word appears to start normally, and the file can be edited on screen. [snip] > > 3. Attempting to save the file gets no response. The only way to close > > the window is to exit without saving! [snip] > > Sounds like an instance of > <http://cygwin.com/ml/cygwin/2005-05/msg00587.html>... Does it work if > you "cygstart cmd" and then start word from that cmd shell? If you get > the same symptoms, please run "set" in that cmd window and compare the > output with the same in a cmd started via "Start->Run"... I get the same symptoms, and now I can see what the problem is. The CMD window shows that TEMP and TMP have retained Cygwin-style pathnames: TEMP=/cygdrive/c/DOCUME~1/dave/LOCALS~1/Temp TMP=/cygdrive/c/DOCUME~1/dave/LOCALS~1/Temp Word works OK if I set TMP to a proper Windows pathname e.g. D:\cygwin\tmp > > Do you get the same problem if you use "run winword.exe filename"? Which > version of Word are you trying to use? No. Everything worked normally when I did the following: export PATH='/cygdrive/c/program files/microsoft office/office11':"$PATH" run winword paper1.doc The problem seems to be specific to commands started by cygstart (with the current Cygwin dll) but isn't specific to one version of Word - I've seen it with both Word 2003 and Word 2000. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
strange cygstart bug with current Cygwin versions
I have encountered a strange bug when starting Microsoft Word when it is started by the cygstart command, e.g. "cygstart Index.doc", with the current version of the Cygwin dll. The symptoms are as follows: 1. Word appears to start normally, and the file can be edited on screen. 2. However, when Word should be autosaving, a message appears to the effect that the auto-recovery save has been postponed. 3. Attempting to save the file gets no response. The only way to close the window is to exit without saving! To attempt to reproduce the bug, you need to open a Word document using cygstart, change the document, then try to save it. I have seen this bug on two of the three computers which I use - all with the latest release of Cygwin. Reverting to the previous version doesn't help, but the bug goes away if I restore a pre-January version of Cygwin. It also goes away if I invoke the Word binary (winword.exe) directly from the command line or a shell script. The two affected computers use different software versions - one has Win2000 with Office 2000, but the other has WinXP with Office 2003. Strangely a third machine with WinXP/Office 2003 is not affected. However, it does seem likely to me that other people will be able to reproduce the bug, as it clearly isn't tied to one particular version of the software. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Missing /bin/sh link
>David Picton wrote: >> I'd like to know whether other people have seen this problem. I did a >> new installation on a C disk and found that files were missing. The >> cause was a missing link - no /bin/sh. I did 'ln -s ash.exe sh.exe' and >> reinstalled the packages, and all was well. > sh is meant to be bash these days. Check in /etc/postinstall and see if > it has 00bash.sh or 00bash.sh.done, and in either case, remove the link > and (re-)run the script. (Make sure no other cygwin processes or > services are running except for the one bash shell you're using to > do this). This worked - thanks! It's all very mysterious, though. 00ash.sh.done and 00bash.sh.done are both there, and work OK when called from a cygwin session - but they seem not to have worked during the install. Could the cause be a problem with cygcheck? *Disclaimer This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. Serco cannot guarantee that the e-mail or any attachments are free from viruses. The views expressed in this e-mail are those of the originator and do not necessarily represent the views of Serco. Nothing in this e-mail shall bind Serco in any contract or obligation. Serco Group plc. Registered in England and Wales. No: 2048608 Registered Office: Serco House, 16 Bartley Wood Business Park, Bartley Way, Hook, Hampshire, RG27 9UY, United Kingdom. *End Disclaimer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Missing /bin/sh link
I'd like to know whether other people have seen this problem. I did a new installation on a C disk and found that files were missing. The cause was a missing link - no /bin/sh. I did 'ln -s ash.exe sh.exe' and reinstalled the packages, and all was well. *Disclaimer This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. Serco cannot guarantee that the e-mail or any attachments are free from viruses. The views expressed in this e-mail are those of the originator and do not necessarily represent the views of Serco. Nothing in this e-mail shall bind Serco in any contract or obligation. Serco Group plc. Registered in England and Wales. No: 2048608 Registered Office: Serco House, 16 Bartley Wood Business Park, Bartley Way, Hook, Hampshire, RG27 9UY, United Kingdom. *End Disclaimer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
