Re: [ANNOUNCEMENT] Updated: bash-3.2.25-17
On Fri, 19 Oct 2007, Corinna Vinschen wrote: On Oct 19 09:46, Igor Peshansky wrote: On Fri, 19 Oct 2007, Eric Blake wrote: According to Igor Peshansky on 10/19/2007 7:29 AM: I could, but the issue is more basic than where the script lives. Right now Cygwin populates the /dev directory as a virtual directory within the DLL. The script I'm talking about will make /dev a real directory, and the only thing Cygwin will deal with is devices. I don't see the point. Ok, fair enough. There was a mailing list discussion a while ago that involved Christopher Faylor stating that he'd like to see such functionality at some point, so I figured I'd work on a script to do that. If Cygwin wants to keep the files in /dev virtual, I have no problems keeping the current create_devices.sh script. What the transition would entail is not clear to me. But the bash postinstall script already creates /dev as a real directory, as of my release announcement; it just isn't very populated. I think making the script its own package in base, then making bash depend on that package, would be worthwhile. ...and the syslog-ng-config as well as the syslogd-config scripts also create /dev if it doesn't exist so that syslog-ng/syslogd can create a /dev/log socket. Yes, I already corrected myself that I meant the files in /dev, not /dev itself. Sorry, I was imprecise. Whether /dev is a real directory or not is irrelevant. However, the *files* in /dev are virtual, and therefore the command mknod -m 666 c 1 3 /dev/null will fail, because, as far as the Cygwin DLL is concerned, /dev/null already exists. Plus, we might get into some ordering issues on when to run this script... I'm under the impression you're thinking about this too complicated. The script could be a postinstall script in the Base category, so it's getting run automatically on install. Cygwin itself does not depend on the existence of /dev, so there's no problem with order or so. For the virtual devices which are handled by Cygwin you don't need to call mknod. Just create empty files, like this: $ touch `cygpath -am /dev`/null $ ls -l /dev/null crw-rw-rw- 1 corinna root 1, 3 Dec 1 2006 /dev/null As you can see, Cygwin does never evaluate a DOS path as virtual device, while it always evaluates the POSIX path into the virtual device. Voila. That is exactly what the current create_devices.sh does. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- 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.2.25-17
On Oct 19 09:46, Igor Peshansky wrote: On Fri, 19 Oct 2007, Eric Blake wrote: According to Igor Peshansky on 10/19/2007 7:29 AM: I could, but the issue is more basic than where the script lives. Right now Cygwin populates the /dev directory as a virtual directory within the DLL. The script I'm talking about will make /dev a real directory, and the only thing Cygwin will deal with is devices. I don't see the point. What the transition would entail is not clear to me. But the bash postinstall script already creates /dev as a real directory, as of my release announcement; it just isn't very populated. I think making the script its own package in base, then making bash depend on that package, would be worthwhile. ...and the syslog-ng-config as well as the syslogd-config scripts also create /dev if it doesn't exist so that syslog-ng/syslogd can create a /dev/log socket. Sorry, I was imprecise. Whether /dev is a real directory or not is irrelevant. However, the *files* in /dev are virtual, and therefore the command mknod -m 666 c 1 3 /dev/null will fail, because, as far as the Cygwin DLL is concerned, /dev/null already exists. Plus, we might get into some ordering issues on when to run this script... I'm under the impression you're thinking about this too complicated. The script could be a postinstall script in the Base category, so it's getting run automatically on install. Cygwin itself does not depend on the existence of /dev, so there's no problem with order or so. For the virtual devices which are handled by Cygwin you don't need to call mknod. Just create empty files, like this: $ touch `cygpath -am /dev`/null $ ls -l /dev/null crw-rw-rw- 1 corinna root 1, 3 Dec 1 2006 /dev/null As you can see, Cygwin does never evaluate a DOS path as virtual device, while it always evaluates the POSIX path into the virtual device. Voila. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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.2.25-17
On Fri, 19 Oct 2007, Eric Blake wrote: According to Igor Peshansky on 10/19/2007 7:29 AM: Why not create a stand-alone package in the base category which consists of just the postinstall script? I could, but the issue is more basic than where the script lives. Right now Cygwin populates the /dev directory as a virtual directory within the DLL. The script I'm talking about will make /dev a real directory, and the only thing Cygwin will deal with is devices. What the transition would entail is not clear to me. But the bash postinstall script already creates /dev as a real directory, as of my release announcement; it just isn't very populated. I think making the script its own package in base, then making bash depend on that package, would be worthwhile. Sorry, I was imprecise. Whether /dev is a real directory or not is irrelevant. However, the *files* in /dev are virtual, and therefore the command mknod -m 666 c 1 3 /dev/null will fail, because, as far as the Cygwin DLL is concerned, /dev/null already exists. Plus, we might get into some ordering issues on when to run this script... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- 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.2.25-17
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Igor Peshansky on 10/19/2007 7:29 AM: Why not create a stand-alone package in the base category which consists of just the postinstall script? I could, but the issue is more basic than where the script lives. Right now Cygwin populates the /dev directory as a virtual directory within the DLL. The script I'm talking about will make /dev a real directory, and the only thing Cygwin will deal with is devices. What the transition would entail is not clear to me. But the bash postinstall script already creates /dev as a real directory, as of my release announcement; it just isn't very populated. I think making the script its own package in base, then making bash depend on that package, would be worthwhile. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHGLLB84KuGfSFAYARAiQ9AKDZny1eTSyCP9dKKLjRzrj+iBO0GACeP2oy As9WTODJsVbFc4T/vlEc3Ro= =DaVD -END PGP SIGNATURE- -- 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.2.25-17
On Fri, 19 Oct 2007, Corinna Vinschen wrote: On Oct 18 13:29, Igor Peshansky wrote: On Wed, 17 Oct 2007, Eric Blake wrote: [snip] Based on user response, I may be convinced to fold in the rest of Igor's create_devices.sh [see http://cygwin.com/cygwin-ug-net/using-specialnames.html] into the bash postinstall, as it admittedly looks a bit weird when 'ls /dev' shows /dev/stdin but not /dev/null (rest assured, all the devices still exist, even if a listing of /dev does not show them). FYI, mknod works just fine on Cygwin, and I've been using a /ddev directory populated with mknod for a while now (not in scripts, of course) with no problems. I have a preliminary version of a modified script that uses mknod to populate a directory with devices. Should we use that instead (and put this in a postinstall script for the cygwin package)? Why not create a stand-alone package in the base category which consists of just the postinstall script? I could, but the issue is more basic than where the script lives. Right now Cygwin populates the /dev directory as a virtual directory within the DLL. The script I'm talking about will make /dev a real directory, and the only thing Cygwin will deal with is devices. What the transition would entail is not clear to me. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- 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.2.25-17
On Oct 18 13:29, Igor Peshansky wrote: On Wed, 17 Oct 2007, Eric Blake wrote: [snip] Based on user response, I may be convinced to fold in the rest of Igor's create_devices.sh [see http://cygwin.com/cygwin-ug-net/using-specialnames.html] into the bash postinstall, as it admittedly looks a bit weird when 'ls /dev' shows /dev/stdin but not /dev/null (rest assured, all the devices still exist, even if a listing of /dev does not show them). FYI, mknod works just fine on Cygwin, and I've been using a /ddev directory populated with mknod for a while now (not in scripts, of course) with no problems. I have a preliminary version of a modified script that uses mknod to populate a directory with devices. Should we use that instead (and put this in a postinstall script for the cygwin package)? Why not create a stand-alone package in the base category which consists of just the postinstall script? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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.2.25-17
On Wed, 17 Oct 2007, Eric Blake wrote: [snip] Based on user response, I may be convinced to fold in the rest of Igor's create_devices.sh [see http://cygwin.com/cygwin-ug-net/using-specialnames.html] into the bash postinstall, as it admittedly looks a bit weird when 'ls /dev' shows /dev/stdin but not /dev/null (rest assured, all the devices still exist, even if a listing of /dev does not show them). FYI, mknod works just fine on Cygwin, and I've been using a /ddev directory populated with mknod for a while now (not in scripts, of course) with no problems. I have a preliminary version of a modified script that uses mknod to populate a directory with devices. Should we use that instead (and put this in a postinstall script for the cygwin package)? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- 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/
[ANNOUNCEMENT] Updated: bash-3.2.25-17
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A new release of bash, 3.2.25-17, has been uploaded, replacing 3.2.25-16
as current, and leaving 3.1-6 as previous.
NEWS:
=
This is a minor patch release. It fixes a bug in (times file) | cat,
introduced in -11. It incorporates a patch that retries up to 4 times
over the course of 15 seconds if fork() fails with EAGAIN. It also
updates the postinstall script to guarantee that /dev/std{in,out,err} and
/dev/fd exist. Based on user response, I may be convinced to fold in the
rest of Igor's create_devices.sh [see
http://cygwin.com/cygwin-ug-net/using-specialnames.html] into the bash
postinstall, as it admittedly looks a bit weird when 'ls /dev' shows
/dev/stdin but not /dev/null (rest assured, all the devices still exist,
even if a listing of /dev does not show them).
There are a few things you should be aware of before using this version:
1. When using binary mounts, cygwin programs try to emulate Linux. Bash
on Linux does not understand \r\n line endings, but interprets the \r
literally, which leads to syntax errors or odd variable assignments.
Therefore, you will get the same behavior on Cygwin binary mounts by default.
2. d2u is your friend. You can use it to convert any problematic script
into binary line endings.
3. Cygwin text mounts automatically work with either line ending style,
because the \r is stripped before bash reads the file. If you absolutely
must use files with \r\n line endings, consider mounting the directory
where those files live as a text mount. However, text mounts are not as
well tested or supported on the cygwin mailing list, so you may encounter
other problems with other cygwin tools in those directories.
4. This version of bash has a cygwin-specific shell option, named igncr
to force bash to ignore \r, independently of cygwin's mount style. As of
bash-3.2.3-5, it controls regular scripts, command substitution, and
sourced files. I hope to convince the upstream bash maintainer to accept
this patch into the future bash 4.0 even on Linux, rather than keeping it
a cygwin-specific patch, but only time will tell. There are several ways
to activate this option:
4a. For a single affected script, add this line just after the she-bang:
(set -o igncr) 2/dev/null set -o igncr; # comment is needed
4b. For a single script, invoke bash explicitly with the shopt, as in
'bash -o igncr ./myscript' rather than the simpler './myscript'.
4c. To affect all scripts, export the environment variable BASH_ENV,
pointing to a file that sets the shell option as desired. Bash will
source this file on startup for every script.
4d. Added in the bash-3.2-2 release: export the environment variable
SHELLOPTS with igncr included in it. It is read-only from within bash,
but you can set it before invoking bash; once in bash, it auto-tracks the
current state of 'set -o igncr'. If exported, then all bash child
processes inherit the same option settings; with the exception added in
3.2.9-11 that certain interactive options are not inherited in
non-interactive use.
5. You can also experiment with the IFS variable for controlling how bash
will treat \r during variable expansion.
6. Normally, cygwin treats DOS-style paths as binary only. This release
of bash includes a hack to check the underlying mount point of files, even
when passed as DOS style paths, but other cygwin tools do not. You are
better off learning how to use POSIX-style paths.
7. There are varying levels of speed at which bash operates. The fastest
is on a binary mount with igncr disabled (the default behavior). Next
would be text mounts with igncr disabled and no \r in the underlying file.
Next would be binary mounts with igncr enabled. And the slowest that bash
will operate is on text mounts with igncr enabled.
8. If you don't like how bash behaves, then propose a patch, rather than
proposing idle ideas. This turn of events has already been talked to
death on the mailing lists by people with many ideas, but few patches.
9. If you forget to read this release announcement, the best you can
expect when you complain to the list is a link back to this email.
Remember, you must not have any bash or /bin/sh instances running when you
upgrade the bash package. This release requires cygwin-1.5.24-1 or
later; and it requires libreadline6-5.2.7-9. See also the upstream
documentation in /usr/share/doc/bash-3.2.25/.
DESCRIPTION:
Bash is an sh-compatible shell that incorporates useful features from the
Korn shell (ksh) and C shell (csh). It is intended to conform to the IEEE
POSIX P1003.2/ISO 9945.2 Shell and Tools standard. It offers functional
improvements over sh for both programming and interactive use. In
addition, most sh scripts can be run by Bash without modification.
As of the bash 3.0 series, cygwin /bin/sh defaults to bash, not ash,
similar to Linux distributions.
UPDATE:
===
To update your installation, click on the Install Cygwin now link on the
