From: Cesar S. <ces...@gm...> - 2012-11-29 21:48:07
|
Dear MSYS users, The latest MSYS runtime, version 1.0.18, is now available. New features: * Globbing characters (* and ?) in the command-line will be automatically quoted when invoking native applications. * MSYS now works if the /etc directory is absent, by monitoring the filesystem in case /etc/fstab is created. Bug fixes: * Be more robust when dealing with ambiguous paths and mount points (eg. /usr/tmp vs. /tmp, considering that /usr and / are the same). To upgrade with mingw-get: 1) mingw-get update 2) mingw-get upgrade msys-core-bin msys-core-ext msys-core-doc msys-core-lic Or, simply type "mingw-get upgrade" to upgrade everything to their latest versions. Caveat: you need to shut down any active MSYS processes, and run these commands from cmd.exe, or from an alternate MSYS installation. See the complete file list and read the full detailed release notes at: http://sourceforge.net/projects/mingw/files/MSYS/Base/msys-core/msys-1.0.18-1/ Feel free to ask questions about using MSYS on the mingw-users mailing list. Discussions about development of MSYS itself are welcomed on the mingw-msys mailing list. The sourceforge trackers are available for bug reports, patch submissions and feature requests. Please be patient, as developer time is very limited currently. Regards, Cesar |
From: niXman <i.n...@gm...> - 2012-11-29 21:58:19
|
2012/11/30 Cesar Strauss: > Dear MSYS users, > > The latest MSYS runtime, version 1.0.18, is now available. > > New features: > > * Globbing characters (* and ?) in the command-line will be > automatically quoted when invoking native applications. > > * MSYS now works if the /etc directory is absent, by monitoring the > filesystem in case /etc/fstab is created. > > Bug fixes: > > * Be more robust when dealing with ambiguous paths and mount points > (eg. /usr/tmp vs. /tmp, considering that /usr and / are the same). > > To upgrade with mingw-get: > > 1) mingw-get update > 2) mingw-get upgrade msys-core-bin msys-core-ext msys-core-doc msys-core-lic > > Or, simply type "mingw-get upgrade" to upgrade everything to their > latest versions. > > Caveat: you need to shut down any active MSYS processes, and run these > commands from cmd.exe, or from an alternate MSYS installation. > > See the complete file list and read the full detailed release notes at: > > http://sourceforge.net/projects/mingw/files/MSYS/Base/msys-core/msys-1.0.18-1/ > > Feel free to ask questions about using MSYS on the mingw-users mailing list. > > Discussions about development of MSYS itself are welcomed on the > mingw-msys mailing list. > > The sourceforge trackers are available for bug reports, patch > submissions and feature requests. Please be patient, as developer time > is very limited currently. > > Regards, > > Cesar Thank you. But tell me please, MSYS make doesn't hang up any more? ;) -- Regards, niXman ___________________________________________________ Dual-target(32 & 64-bit) MinGW compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingwbuilds/ |
From: Renato S. <br....@gm...> - 2012-11-30 03:31:25
|
My /etc/profile was overwritten in the update. If it wasn't the previous version feature from Windows, it would have been lost. My modifications to /etc/profile were one for MinGW/MSYS not taking precedence over Windows utilities with same name in PATH (such as find), and another for sourcing a script to circumvent a timezone bug. What else is at the risk of having been get overwritten? |
From: Eli Z. <el...@gn...> - 2012-11-30 08:29:37
|
> From: Renato Silva <br....@gm...> > Date: Fri, 30 Nov 2012 01:30:39 -0200 > > My /etc/profile was overwritten in the update. If it wasn't the previous > version feature from Windows, it would have been lost. I suggest to always unpack the new version in another directory, and compare the contents to the old one. Even if the developers took all the precautions not to overwrite your precious customizations, there are always bugs and oversight, and there's no end to users' ingenuity of changing files that were never meant to be changed. So stuff happens. And for those who want to use the "previous version" feature of Windows: be warned that by default only the system disk is covered. If you have drives other than C:, you need to turn that feature ON for those other drives. |
From: Keith M. <kei...@us...> - 2012-11-30 12:37:20
|
On 30 November 2012 03:30, Renato Silva wrote: > My /etc/profile was overwritten in the update. This is correct, expected behaviour. > If it wasn't [for] the previous version feature from Windows, it > would have been lost. I sympathise, (and I'm pleased that you had a backup), but I do feel obliged to point out that you are the victim of your own PEBKAC here. > My modifications to /etc/profile were ... Entirely inappropriate. As a distributable system component, the prerogative for modifying this file lies with the project maintainer. As a user, you have neither any need to, nor should you modify this file; there are four legitimate hooks available to you, which are completely adequate to achieve any level of customisation you may require, without any need for you to abuse this prerogative of the maintainer: 1) Make your customisations in $HOME/.bash_profile, for those which are to apply to bash --login sessions; 2) Make customisations in $HOME/.profile, for sh --login sessions; (these will also apply for bash --login, IFF you don't furnish $HOME/.bash_profile); 3) Specify non-login shell customisations in $HOME/.bashrc; (note that these will not apply to login shells, unless you also source $HOME/.bashrc in $HOME/.profile and/or $HOME/.bash_profile, as appropriate); 4) If user-specific customisations aren't sufficient, add a custom hook script, (or more than one, if you prefer), in /etc/profile.d; (anything you place here is your's to maintain, in perpetuity, and will be sourced by /etc/profile at login shell invocation). > one for MinGW/MSYS not taking precedence over Windows utilities with > same name in PATH (such as find), Well, each to his own; I would always prefer the MSYS "find" to the crippled ersatz "grep" which Microsoft call "find" :), but I would most likely have used $HOME/.profile or $HOME/.bash_profile, to implement a start-up hook such as this. > and another for sourcing a script to circumvent a timezone bug. The natural way to accomplish that would, surely, have been just to drop that script into /etc/profile.d, (a directory, which you may have needed to create), whence /etc/profile would have sourced it, without any change in /etc/profile itself. > What else is at the risk of having been get overwritten? Anything else you may have modified inappropriately. -- Regards, Keith. |
From: Renato S. <br....@gm...> - 2012-11-30 21:03:04
|
2012/11/30 Keith Marshall <kei...@us...> > Entirely inappropriate. As a distributable system component, the > prerogative for modifying this file lies with the project maintainer. > I assumed /etc as a configuration dir, therefore modifiable like in true unixes. Actually, now I wonder how exactly it is there, when updates take place. I remember for example, seeing diff dialogs when upgrading Ubuntu for files in /etc that I hadn't modified myself, but I think they have somehow annihilated such end-user insanity these days. Anyway, point taken. However, how about /etc/fstab? My customizations weren't overwritten for this file. > 4) If user-specific customisations aren't sufficient, add a custom > hook script, (or more than one, if you prefer), in /etc/profile.d; > (anything you place here is your's to maintain, in perpetuity, > and will be sourced by /etc/profile at login shell invocation). > I have moved the timezone script to that directory, and it worked fine except that we need to add the .sh extension. > Well, each to his own; I would always prefer the MSYS "find" to the > crippled ersatz "grep" which Microsoft call "find" :), but I would > most likely have used $HOME/.profile or $HOME/.bash_profile, to > implement a start-up hook such as this. > I took a look at the Windows setting for PATH, and it was actually for avoiding duplicated items, because I had moved the MinGW/MSYS bin items to the Windows setting for PATH, so that it is MinGW/MSYS, actually, that takes precedence over Windows utilities with same name, when using cmd.exe or similar. That was also for having MSYS utilities available outside bash in general, for example not just cmd.exe (if I'm forced to use it for any reason, e.g. for applying the announced update) but also from shortcuts, scheduled tasks, etc. So yes, Windows' find is horrible, and I think using sed or similar to remove duplication from PATH would be uglier than just ignoring it: /usr/local/bin /mingw/bin /bin => this and above come from /etc/profile /usr/local => this and below come from Windows /usr/local/msls /usr/local/msvcrt /usr/local/iconv /mingw/bin /usr/bin |
From: Keith M. <kei...@us...> - 2012-11-30 22:18:21
|
On 30/11/12 21:02, Renato Silva wrote: > Anyway, point taken. However, how about /etc/fstab? My customizations > weren't overwritten for this file. In MSYS, /etc/fstab is a historical anomaly; it isn't used as its namesake on traditional unix systems, isn't distributed, and should really have been called /etc/mtab or /etc/mnttab, (for these are its closest analogues in such traditional unix systems). In MSYS usage today, /etc/fstab is created dynamically when you mount its virtual file systems; (historically, the mount command didn't fulfil this function; you "mounted" file systems by editing /etc/fstab directly). > 4) If user-specific customisations aren't sufficient, add a custom > hook script, (or more than one, if you prefer), in /etc/profile.d; > (anything you place here is your's to maintain, in perpetuity, > and will be sourced by /etc/profile at login shell invocation). > > I have moved the timezone script to that directory, and it worked fine > except that we need to add the .sh extension. Which is how it is on my Debian system too. I guess the idea is to discriminate between initialisation scripts for Bourne class shells, and those for other shells; of course, we don't offer alternative (non-Bourne) shells with MSYS. > That was also for having MSYS utilities available outside bash in general, We neither endorse, nor support such usage. It may work, sometimes; it may also go horribly wrong. YMMV, but if it blows up in your face, you are on your own. > for example not just cmd.exe (if I'm forced to use it for any reason, > e.g. for applying the announced update) But, you aren't running an MSYS application when you do this; (in fact you must not be running any MSYS application in any process on the box). Eventually, you won't use cmd.exe to launch mingw-get when you perform such upgrades; you will use the GUI, (as I did last night, as a test of my current development prototype). -- Regards, Keith. |