Re: [ERROR] Locale Monetary Symbol Prints Wrongly on Windows : Cygwin
On 2023-03-13 21:44, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: Please pay close attention to how the command was shown to you, including the use of the whitespace: $ LC_MONETARY="en_ZM.utf-8" locale -ck LC_MONETARY In the terminal, when I use $LC_MONETARY = "en_ZM.utf-8" locale -ck LC_MONETARY Cygwin replies "-bash: LC_MONETARY: command not found" The dollar sign in there was the shell prompt; not something you have to type. So, this is basically what and how you should enter it: LC_MONETARY="en_ZM.utf-8" locale -ck LC_MONETARY Try it using a known good locale first, then that locale. Shut down all Cygwin processes. Run setup-x86_64: Select Packages/View Full/Search cygwin/column New dropdown/bottom entry/3.5.0-0.231.g93f70d7849b8, same for -devel and -doc if desired, then Search Clear, reset View Pending, then Next, ... Run your terminal, redo the commands above, and you should see correct data. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ERROR] Locale Monetary Symbol Prints Wrongly on Windows : Cygwin
Please pay close attention to how the command was shown to you, including the use of the whitespace: > >$ LC_MONETARY="en_ZM.utf-8" locale -ck LC_MONETARY > In the terminal, when I use $LC_MONETARY = "en_ZM.utf-8" locale -ck > LC_MONETARY > Cygwin replies "-bash: LC_MONETARY: command not found" The dollar sign in there was the shell prompt; not something you have to type. So, this is basically what and how you should enter it: LC_MONETARY="en_ZM.utf-8" locale -ck LC_MONETARY HTH, Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ERROR] Locale Monetary Symbol Prints Wrongly on Windows : Cygwin
Hi Corinna,
I can't update to 3.5+, I tried reinstalling using the Cygwin setup
Using "uname -a", my current version is 3.4.6-1.x86_64.
I assume 3.5 hasn't been released officially.
May I know where to get the test release?
In the terminal, when I use $LC_MONETARY = "en_ZM.utf-8" locale -ck
LC_MONETARY
Cygwin replies "-bash: LC_MONETARY: command not found"
Thank you very much.
Kind Regards,
YEO Kai Wei
On 13/3/2023 6:49 pm, Corinna Vinschen wrote:
On Mar 13 08:40, Yeo Kai Wei via Cygwin wrote:
Hi All,
May I ask if there's a bug with Cygwin and Windows currency?
The en_ZM locale isn't yet supported by Cygwin. This will change with
Cygwin 3.5.0. You can install the latest Cygwin test release
3.5.0-0.231.g93f70d7849b8 and retry. You'll get the correct output:
Region: en_AU.utf-8 Currency symbol: $ International currency symbol: AUD
Region: en_CA.utf-8 Currency symbol: $ International currency symbol: CAD
Region: en_GB.utf-8 Currency symbol: £ International currency symbol: GBP
Region: en_US.utf-8 Currency symbol: $ International currency symbol: USD
Region: en_NZ.utf-8 Currency symbol: $ International currency symbol: NZD
Region: en_ZM.utf-8 Currency symbol: K International currency symbol: ZMW
Btw., you don't even need a test application, just call
$ LC_MONETARY="en_ZM.utf-8" locale -ck LC_MONETARY
The correct answer should be "Region: en_ZM.utf-8 Currency symbol: K
International currency symbol: ZMK"
Supposedly, the code works on Linux.
Is this an issue with Windows?
We're fetching most locale information from Windows, this includes the
LC_MONETARY information. However, the locale support up to Cygwin 3.4.x
is restricted by an issue in Windows:
Originally, locales were handled in Windows by using so called locale
identifiers, LCID, 2 byte numbers. These LCIDs are used by Cygwin
internally.
In the meantime, Windows switched from LCIDs to locale string
identifiers following RFC 4646 resp. RFC 5646. Now, the problem is this:
Cygwin didn't yet follow suite, still using LCIDs internally, but
Windows introduced locales for which no LCID has ever been assigned.
Asking for the LCID for "en-ZW" returns 0.
For Cygwin 3.5.0, I converted Cygwin to use RFC 5646 locale strings
internally, too, so the next major version of Cygwin will be able to
support all locales Windows supports.
while (regions[i])
{
setlocale(LC_MONETARY, regions[i]);
You're not checking for errors here. If the locale isn't supported,
setlocale should return NULL...
const struct lconv* loc = localeconv();
...and the locale information stays unchanged. As such, if en_ZM isn't
supported, this call will still fetch the information of the en_NZ.utf-8
locale.
HTH,
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Test: gcc-11.3.1+20230310-0.1
On 3/11/2023 1:50 PM, Achim Gratz via Cygwin wrote: The native Gcc compilers have been updated to the latest upstream snapshot version of the gcc-11 branch: gcc-11.3.1+20230310 Thanks! I've given it a pretty good workout with builds of Emacs and TeX Live, and everything seems good so far. This release includes libgccjit as a separate package for the native toolchain. Since Cygwin does not yet enable ASLR by default, any nontrivial dynamic objects that are created in this way will likely need to get rebased before they can be used. It is unlikely that build systems recognize the need for doing that at the moment. FYI, following a suggestion made by Corinna on IRC, I'm building all the Emacs libraries (.eln files as well as tree-sitter grammar libs) with ASLR enabled and no rebasing. I have about 400 of these libraries on my system. I've been doing this for about a month without any fork failures. Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Test : cmake 3.25.3-1
Test version 3.25.3-1 of cmake cmake-doc cmake-gui emacs-cmake bash-completion-cmake vim-cmake are available in the Cygwin distribution. CHANGES Latest upstream release DESCRIPTION CMake is an open-source, cross-platform family of tools designed to build, test and package software HOMEPAGE http://www.cmake.org/ Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Test : cmake 3.25.3-1
Test version 3.25.3-1 of cmake cmake-doc cmake-gui emacs-cmake bash-completion-cmake vim-cmake are available in the Cygwin distribution. CHANGES Latest upstream release DESCRIPTION CMake is an open-source, cross-platform family of tools designed to build, test and package software HOMEPAGE http://www.cmake.org/ Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com .
Re: service interruption :-(
On 13/03/2023 10:30, marco atzeri via Cygwin-apps wrote: Hi Guys, just to inform you that my old laptop is seriously considering to retire itself ; it froze several time this early morning. I will need to buy and configure a new laptop before being fully operative again. Sorry to hear that. In the mean time if someone can upload job 5600 as test, I will appreciate. It is the latest upstream cmake 3.25.3 with python3.9 I did this for you. (I needed to rebuild with the test: label applied as there's no mechanism for applying it afterwards)
Re: Possible "stage" token for SCALLYWAG builds
On 2/16/2023 7:13 PM, Ken Brown via Cygwin-apps wrote: On 2/16/2023 3:31 PM, Jon Turney wrote: On 15/02/2023 21:48, Ken Brown via Cygwin-apps wrote: Jon, When building TeX Live (once a year), I have to build texlive, asymptote, and all the texlive-collection-* packages. I currently can't use SCALLYWAG to do the builds because these packages need to all be deployed at once. So I have to build them all locally, upload them to my staging area, and then upload !ready files, one for x86_64 and one for noarch. It would be convenient for me if SCALLYWAG would accept a "stage" token that would upload the files to my staging area without deploying them. Then I could let SCALLYWAG do the builds, and I could upload the !ready files when everything is staged. If I'm the only maintainer who would find this useful, then I can continue doing it the way I always have. But maybe others would find it useful too. I'm not opposed to adding a some feature to support this if needed, but from the way you are describing it, this sounds more like a constraint that the dependency solver should be aware of. (just because texlive-2023 and texlive-collection-foo-2023 are made available to download at the same time, doesn't mean that they always end up installed together, as the user might alter the version of one or the other) If they really must be kept in lockstep to work correctly, then there's at least a couple of ways of doing that: * give texlive an additional provide, such as texlive_2023, and make everything that requires it, require that (something similar is done with perl and perl modules) * make things which require texlive do so with a version constraint like 'requires: texlive (>= 2023), texlive (<2024)' (in theory this works, but I have no doubt that a bug will emerge when someone tries to use it, and ofc, it relies on the range of future versions which are compatible being correctly known in advance) Thanks for the suggestions. I think I should be able to make things work with one or both of your ideas. Just to finish this off for the sake of the archives, here's the solution I've decided on. First, the only two packages that absolutely have to be in lockstep are texlive and texlive-collection-basic. I achieve this as follows: - Make texlive provide tl_2023 and require tl_basic_2023. - Make texlive-collection-basic provide tl_basic_2023 and require tl_2023. In addition, I prefer (but don't require) that the other texlive-collection-* packages stay in lockstep with texlive and texlive-collection-basic. To this end, - Make the other texlive-collection-* packages require tl_basic_2023. As long as I deploy texlive after all the collections, I get what I want. Alternatively, I could deploy texlive-collection-basic after all the other collections. If I forget to do one of those things, it won't be a disaster. I've done some local testing, and this appears to work. Ken
Re: [PATCH] Cygwin: doc: Update postinstall/preremove scripts
On Mar 13 14:18, Jon Turney wrote:
> On 13/03/2023 09:31, Corinna Vinschen wrote:
> > Hi Jon,
> >
> > On Mar 8 14:17, Jon Turney wrote:
> > > Update postinstall/preremove scripts to use CYGWIN_START_MENU_SUFFIX and
> > > CYGWIN_SETUP_OPTIONS.
> >
> > It would be great if you could explain your change in the commit
> > message...
> >
>
> Yeah, that's fair. How about:
>
> "Since setup 2.925, it indicates to postinstall and preremove scripts the
> start menu suffix to use via the CYGWIN_START_MENU_SUFFIX env var.
>
> It also indicates, via the CYGWIN_SETUP_OPTIONS env var, if the option to
> disable startmenu shortcut creation is supplied.
>
> Update the Cygwin documentation postinstall and preremove scripts to take
> these env vars into consideration."
Sure, sounds good
>
> > > winsup/doc/etc.postinstall.cygwin-doc.sh | 19 +++
> > > winsup/doc/etc.preremove.cygwin-doc.sh | 8 ++--
> > > 2 files changed, 21 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/winsup/doc/etc.postinstall.cygwin-doc.sh
> > > b/winsup/doc/etc.postinstall.cygwin-doc.sh
> > > index 97f88a16d..313c1d3ff 100755
> > > --- a/winsup/doc/etc.postinstall.cygwin-doc.sh
> > > +++ b/winsup/doc/etc.postinstall.cygwin-doc.sh
> > > @@ -36,9 +36,20 @@ do
> > > fi
> > > done
> > > +# setup was run with options not to create startmenu items
> > > +case ${CYGWIN_SETUP_OPTIONS} in
> > > + *no-startmenu*)
> > > +exit 0
> > > +;;
> > > +esac
> > > +
> > > # Cygwin Start Menu directory
> > > -case $(uname -s) in *-WOW*) wow64=" (32-bit)" ;; esac
> > > -smpc_dir="$($cygp $CYGWINFORALL -P -U --)/Cygwin${wow64}"
> > > +if [ ! -v CYGWIN_START_MENU_SUFFIX ]
> >
> > Isn't -v a bash extension? Ideally the shebang should reflect that.
> > Otherwise, -z?
>
> This is actually controlled by setup, which runs postinstall and preremove
> scripts with an .sh extension using bash.
>
> But yeah, I'll change the shebang.
Great. Just push when you're ready.
Thanks,
Corinna
RE: [EXTERNAL] Re: 3.4.6-1 shm_open always returns -1, errno EINVAL
> > returns 3 and sets errno to zero. Note that "setting errno to zero" is not guaranteed in case of a successful completion of a library function or a system call. Generally, "errno" reflects an error that occurred last when such a call failed (so in other words, in case of a successful completion, "errno" can still carry over an error from a previously failed call). In this particular use case, it looks like "errno" was clear from the get go because nothing was called prior to "shm_open()", and so it remained so when the call returned (successfully). HTH, Anton Lavrentiev Contractor NIH/NLM/NCBI -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: disk space limit of scallywag ?
On 12/03/2023 22:27, Marco Atzeri via Cygwin-apps wrote:
Hi Jon,
will be possible to pass the token notest to the sub-command rerun ?
For the time being I used SCALLYWEG="notest"
Yes, e.g. 'jobs rerun --token notest 5594'
Unfortunately, this can run into well known ssh quotation difficulties
when you want to specify multiple space separated tokens (as the command
is evaluated by the local shell and the the remote shell), so maybe
needs some improvement...
(I think maybe something like ssh cyg...@cygwin.com "jobs rerun --token
'notest label' 5594" works, but I haven't tested it...)
PS: there is a mismatch in the documentation
subcommands:
{cancel,deploy,help,rerun}
cancel cancel job
deploy deploy job
help this help
rerun re-run job
While on the web:
rebuild
rebuild a job (e.g. if it failed due to some transient condition, or
optionally with different tokens).
Thanks for pointing this out. I fixed the documentation.
Re: [PATCH] Cygwin: doc: Update postinstall/preremove scripts
On 13/03/2023 09:31, Corinna Vinschen wrote:
Hi Jon,
On Mar 8 14:17, Jon Turney wrote:
Update postinstall/preremove scripts to use CYGWIN_START_MENU_SUFFIX and
CYGWIN_SETUP_OPTIONS.
It would be great if you could explain your change in the commit
message...
Yeah, that's fair. How about:
"Since setup 2.925, it indicates to postinstall and preremove scripts
the start menu suffix to use via the CYGWIN_START_MENU_SUFFIX env var.
It also indicates, via the CYGWIN_SETUP_OPTIONS env var, if the option
to disable startmenu shortcut creation is supplied.
Update the Cygwin documentation postinstall and preremove scripts to
take these env vars into consideration."
winsup/doc/etc.postinstall.cygwin-doc.sh | 19 +++
winsup/doc/etc.preremove.cygwin-doc.sh | 8 ++--
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/winsup/doc/etc.postinstall.cygwin-doc.sh
b/winsup/doc/etc.postinstall.cygwin-doc.sh
index 97f88a16d..313c1d3ff 100755
--- a/winsup/doc/etc.postinstall.cygwin-doc.sh
+++ b/winsup/doc/etc.postinstall.cygwin-doc.sh
@@ -36,9 +36,20 @@ do
fi
done
+# setup was run with options not to create startmenu items
+case ${CYGWIN_SETUP_OPTIONS} in
+ *no-startmenu*)
+exit 0
+;;
+esac
+
# Cygwin Start Menu directory
-case $(uname -s) in *-WOW*) wow64=" (32-bit)" ;; esac
-smpc_dir="$($cygp $CYGWINFORALL -P -U --)/Cygwin${wow64}"
+if [ ! -v CYGWIN_START_MENU_SUFFIX ]
Isn't -v a bash extension? Ideally the shebang should reflect that.
Otherwise, -z?
This is actually controlled by setup, which runs postinstall and
preremove scripts with an .sh extension using bash.
But yeah, I'll change the shebang.
Re: 'bat' for cygwin
On Mar 10 20:29, Thomas Wolff via Cygwin wrote: > > > Am 10.03.2023 um 19:18 schrieb marco atzeri via Cygwin: > > On Fri, Mar 10, 2023 at 6:58 PM Scott Smith via Cygwin wrote: > > > Has anyone compiled bat for cygwin64? > > > > > > If not, could it be added for consideration to be added to the > > > repository, please? > > > > > > Meanwhile, although I know 0% about Rust, if someone can tell me how to > > > install Rust, then I could take a shot at compiling it myself. > > > > > > Thanks > > > > > Hi Scott, > > sorry but , there is no rust compiler for Cygwin > Also Rust does not support a cygwin build: > https://github.com/rust-lang/rust/issues/79854 https://cygwin.com/acronyms/#SHTDI I guess... Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ERROR] Locale Monetary Symbol Prints Wrongly on Windows : Cygwin
On Mar 13 08:40, Yeo Kai Wei via Cygwin wrote:
> Hi All,
>
> May I ask if there's a bug with Cygwin and Windows currency?
The en_ZM locale isn't yet supported by Cygwin. This will change with
Cygwin 3.5.0. You can install the latest Cygwin test release
3.5.0-0.231.g93f70d7849b8 and retry. You'll get the correct output:
Region: en_AU.utf-8 Currency symbol: $ International currency symbol: AUD
Region: en_CA.utf-8 Currency symbol: $ International currency symbol: CAD
Region: en_GB.utf-8 Currency symbol: £ International currency symbol: GBP
Region: en_US.utf-8 Currency symbol: $ International currency symbol: USD
Region: en_NZ.utf-8 Currency symbol: $ International currency symbol: NZD
Region: en_ZM.utf-8 Currency symbol: K International currency symbol: ZMW
Btw., you don't even need a test application, just call
$ LC_MONETARY="en_ZM.utf-8" locale -ck LC_MONETARY
> The correct answer should be "Region: en_ZM.utf-8 Currency symbol: K
> International currency symbol: ZMK"
>
> Supposedly, the code works on Linux.
>
> Is this an issue with Windows?
We're fetching most locale information from Windows, this includes the
LC_MONETARY information. However, the locale support up to Cygwin 3.4.x
is restricted by an issue in Windows:
Originally, locales were handled in Windows by using so called locale
identifiers, LCID, 2 byte numbers. These LCIDs are used by Cygwin
internally.
In the meantime, Windows switched from LCIDs to locale string
identifiers following RFC 4646 resp. RFC 5646. Now, the problem is this:
Cygwin didn't yet follow suite, still using LCIDs internally, but
Windows introduced locales for which no LCID has ever been assigned.
Asking for the LCID for "en-ZW" returns 0.
For Cygwin 3.5.0, I converted Cygwin to use RFC 5646 locale strings
internally, too, so the next major version of Cygwin will be able to
support all locales Windows supports.
> while (regions[i])
> {
> setlocale(LC_MONETARY, regions[i]);
You're not checking for errors here. If the locale isn't supported,
setlocale should return NULL...
> const struct lconv* loc = localeconv();
...and the locale information stays unchanged. As such, if en_ZM isn't
supported, this call will still fetch the information of the en_NZ.utf-8
locale.
HTH,
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
service interruption :-(
Hi Guys, just to inform you that my old laptop is seriously considering to retire itself ; it froze several time this early morning. I will need to buy and configure a new laptop before being fully operative again. In the mean time if someone can upload job 5600 as test, I will appreciate. It is the latest upstream cmake 3.25.3 with python3.9 Unfortunately I was just at the start of updating all python sub-packages for only 3.8 & 3.9 before working on 3.11. No more activity on 3.6 & 3.7 The following (source) packages were already updated to latest upstream python38 3.8.16-1 python39 3.8.16-1 python-pip23.0.1-1 I assume I will be able to recover the data from disk, but if not I will need some additional time to rebuild them. Regards Marco
Re: [PATCH] Cygwin: Fix type mismatch on sys/cpuset.h -- relnote 3.4.6
This should go into the 3.4.7 release message... On Mar 11 15:36, Mark Geisert wrote: > --- > winsup/cygwin/release/3.4.6 | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/winsup/cygwin/release/3.4.6 b/winsup/cygwin/release/3.4.6 > index ccc168a95..ed124ed37 100644 > --- a/winsup/cygwin/release/3.4.6 > +++ b/winsup/cygwin/release/3.4.6 > @@ -12,3 +12,6 @@ Addresses: > https://cygwin.com/pipermail/cygwin/2023-February/253037.html > > Don't accidentally drop the default ACEs when chmod'ing directories. > Addresses: https://cygwin.com/pipermail/cygwin/2023-February/253037.html > + > +Fix CPU_SET(3) macro type mismatch by making the macros type-safe. > +Addresses https://cygwin.com/pipermail/cygwin/2023-March/253220.html > -- > 2.39.0
Re: [PATCH] Cygwin: Fix type mismatch on sys/cpuset.h
Hi Mark,
looks good to me, codewise. An additional "Fixes:" in the
commit message would be great, i. e.
On Mar 10 02:18, Mark Geisert wrote:
> Addresses https://cygwin.com/pipermail/cygwin/2023-March/253220.html
>
> Take the opportunity to follow FreeBSD's and Linux's lead in recasting
> macro inline code as calls to static inline functions. This allows the
> macros to be type-safe. In addition, added a lower bound check to the
> functions that use a cpu number to avoid a potential buffer underrun on
> a bad argument. h/t to Corinna for the advice on recasting.
Fixes: 362b98b49af5 ("Cygwin: Implement CPU_SET(3) macros")
Thanks,
Corinna
Re: [PATCH] Cygwin: doc: Update postinstall/preremove scripts
Hi Jon,
On Mar 8 14:17, Jon Turney wrote:
> Update postinstall/preremove scripts to use CYGWIN_START_MENU_SUFFIX and
> CYGWIN_SETUP_OPTIONS.
It would be great if you could explain your change in the commit
message...
> winsup/doc/etc.postinstall.cygwin-doc.sh | 19 +++
> winsup/doc/etc.preremove.cygwin-doc.sh | 8 ++--
> 2 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/winsup/doc/etc.postinstall.cygwin-doc.sh
> b/winsup/doc/etc.postinstall.cygwin-doc.sh
> index 97f88a16d..313c1d3ff 100755
> --- a/winsup/doc/etc.postinstall.cygwin-doc.sh
> +++ b/winsup/doc/etc.postinstall.cygwin-doc.sh
> @@ -36,9 +36,20 @@ do
> fi
> done
>
> +# setup was run with options not to create startmenu items
> +case ${CYGWIN_SETUP_OPTIONS} in
> + *no-startmenu*)
> +exit 0
> +;;
> +esac
> +
> # Cygwin Start Menu directory
> -case $(uname -s) in *-WOW*) wow64=" (32-bit)" ;; esac
> -smpc_dir="$($cygp $CYGWINFORALL -P -U --)/Cygwin${wow64}"
> +if [ ! -v CYGWIN_START_MENU_SUFFIX ]
Isn't -v a bash extension? Ideally the shebang should reflect that.
Otherwise, -z?
Thanks,
Corinna
Re: scallywag
On Mar 11 11:54, Ken Brown via Cygwin-apps wrote: > On 3/11/2023 2:18 AM, Marco Atzeri via Cygwin-apps wrote: > > may I propose another PLUSH HIPPO for Jon Turney for > > implementating and maintaining scallywag ? > > Seconded! Thirded! :) Corinna
