Re: cygpath -m behaviour change

> But why are you even using cygpath to try and determine the containing > directory? 'dirname' does that task, in a much more portable manner, > and without having to worry about whether 'file/..' can be abused in > spite of POSIX semantics To given even more context, this is how it was used: u

Re: cygpath -m behaviour change

Hi, the script is attempting to determine the directory in which it exists, so CURRENT_DIR is a bit misleading. This is so that it can access other files in the same package relative to it (quite a common technique I think). Might be helpful to have some examples: /home/dgriff> mkdir test /home/d

Re: cygpath -m behaviour change

> Yes, that's exactly right, assuming that 'boo' doesn't exist. Hi, it happens even if boo does exist. To put it in context, the script in question was attempting to determine the current directory: CURRENT_DIR=$(cygpath -ma "${0}"/../) (I didn't write this script but I assume they did this for

cygpath -m behaviour change

I reinstalled cygwin after a disk failure recently and one of my scripts stopped working. The problem can be easily reproduced by entering: $ cygpath -m boo/.. cygpath: error converting "boo/.." - No such file or directory this is with version 1.7.24(0.269/5/3). On another machine with 1.

Re: vim-7.3.943-1 missing command 'let g:colors_name = "elflord"' found in vim-common-7.3.943-1

Gary Johnson spocom.com> writes: > This is not a bug. See Yaakov's announcement in the list on May 12, > "[ANNOUNCEMENT] Updated: vim-7.3.943-1". He explains that the > packaging scheme has been changed and that /usr/bin/vi is now Vim > compiled with the "small" feature set. The "small" featur