managing autoconf versions?

[Jay]

This is a little off topic.
 
How do people manage autoconf/automake versions?
 
 
In particular, I'm not doing "my own work" -- I could probably just install one 
recent version of everything and be ok.
 
 
Rather I'm wondering about submitting patches to other projects, some projects 
might use one set of versions, or another. Change configure.ac/Makefile.am or 
such and regenerate configure/Makefile.in or such, using a matching toolset 
version so that churn is only what is desired?
 
 
Is the solution to install to various custom prefix and tailor $PATH based on 
context? Or does one "wrapper" sniff the input or output and decide among the 
versions installed in a standard place?
You know, like, input/or output could say # use autoconf 1.2.3
and then /usr/bin/autoconf could delegate to /usr/bin/autoconf-1.2.3
or such?
 
Thanks,
- Jay

--
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: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8

[Lenik]

(This mail is encoded in utf-8)

After tested with 1.7.0-48, many problems are eliminated.

But cygpath doesn't return good pathnames, see:

1, Get absolute path of current directory:

C:\Profiles\Shecti\桌面> set LANG=zh_CN.GBK& cygpath -am .
C:/Profiles/Shecti/桌面 (good)

C:\Profiles\Shecti\桌面> set LANG=zh_CN.GBK& cygpath -au .
/mnt/c/Profiles/Shecti/桌面/ (good)

C:\Profiles\Shecti\桌面> set LANG=zh_CN.UTF-8& cygpath -am .
C:/Profiles/Shecti/ (bad)

C:\Profiles\Shecti\桌面> set LANG=zh_CN.UTF-8& cygpath -au .
/mnt/c/Profiles/Shecti/桌面/ (good)

C:\Profiles\Shecti\桌面> set LANG=C& cygpath -am .
C:/Profiles/Shecti/ (bad)

C:\Profiles\Shecti\桌面> set LANG=C& cygpath -au .
/mnt/c/Profiles/Shecti/桌面/ (good)

Conclusion:
1.1 only GBK works for `cygpath -am .' (also -aw)
1.2 all work for `cygpath -au .'

2, Get absolute path of specified path

C:\Profiles\Shecti\桌面>set LANG=zh_CN.GBK& cygpath -am C:\Profiles 
\Shecti\桌面

C:/Profiles/Shecti/妗岄潰 (bad)

C:\Profiles\Shecti\桌面>set LANG=zh_CN.GBK& cygpath -au C:\Profiles 
\Shecti\桌面

/mnt/c/Profiles/Shecti/妗岄潰 (bad)

C:\Profiles\Shecti\桌面>set LANG=zh_CN.UTF-8& cygpath -am 
C:\Profiles\Shecti\桌面

C:/Profiles/Shecti/ (bad)

C:\Profiles\Shecti\桌面>set LANG=zh_CN.UTF-8& cygpath -au 
C:\Profiles\Shecti\桌面

/mnt/c/Profiles/Shecti/桌面 (good)

C:\Profiles\Shecti\桌面>set LANG=C& cygpath -am C:\Profiles\Shecti\桌面
C:/Profiles/Shecti/ (bad)

C:\Profiles\Shecti\桌面>set LANG=C& cygpath -au C:\Profiles\Shecti\桌面
/mnt/c/Profiles/Shecti/桌面 (good)

Conclusion:
2.1 none works for `cygpath -am PathContainsNonascii'
2.2 GBK doesn't work for `cygpath -au PathContainsNonascii'

Now the problem is, I must use GBK for 1.1, and I cannot use GBK for 
2.2. and no more choice.   -_-||...


Lenik



--
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: libtool, how should the version be parsed?

[René Berber]

Charles Wilson wrote:

[snip]
> So, next time, kindly refrain from accusing my package of insanity.  But
> while we're on the subject...libtool-1.4 dates from 27-Nov-2003, more
> than 5.5 years ago...

Thanks for all the info.  I learned something new.

As for the old version, that's just a requirement, libtool 1.4 or
newer... but since the autoconf script complains it must have taken the
1.3.x as version... yes, it does:

$ libtoolize --version | sed 's/^[^0-9]*\([0-9].[0-9.]*\).*/\1/'
1.3081
2003

2009
...

Weird, its looking for the first number, must be as confused as I am, I
can understand if something is version X and part of say coreutils
version Y, but libtool X being part of "GNU libtool" Y?
-- 
René Berber


--
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: libtool, how should the version be parsed?

[Charles Wilson]

René Berber wrote:
> Hi,
> 
> I was trying to build some package and it complained that libtool 1.4
> was needed... looking at the version:
> 
> $ libtool --version
> libtool (GNU libtool 1.3081 2009-02-17) 2.2.7a
> 
> Is it 1.3081 or 2.2.7a?

It is 2.2.7a.  You can see that from the announcement here:
http://cygwin.com/ml/cygwin-announce/2009-04/msg3.html
"[1.7] Updated: {libtool/libltdl7}-2.2.7a-12"
   ^^

Also:

$ cygcheck -cd libtool
Package  Version
libtool  2.2.7a-12

> I see at gnu.org that the latest stable is 2.2.6a, so I suppose the one
> in Cygwin (1.7) is the bleeding edge.  Any trick/idea on how to use it
> with packages that expect something sane as version.

This format
   "libtool (GNU libtool 1.3081 2009-02-17) 2.2.7a"
is the GNU standard, as documented here:
http://www.gnu.org/prep/standards/standards.html#g_t_002d_002dversion

> The first line is meant to be easy for a program to parse; the version
> number proper starts after the last space."

Also

> If the program is a subsidiary part of a larger package, mention the
> package name in parentheses, like this:
>
>  emacsserver (GNU Emacs) 19.30
>
> If the package has a version number which is different from this
> program's version number, you can mention the package version number
> just before the close-parenthesis.

So, if you had build stock libtool-2.2.6(a), and ran --version on it,
you would have seen:

libtool (GNU libtool 1. 2008-mm-dd) 2.2.6a

So, next time, kindly refrain from accusing my package of insanity.  But
while we're on the subject...libtool-1.4 dates from 27-Nov-2003, more
than 5.5 years ago...

--
Chuck

--
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/

libtool, how should the version be parsed?

[René Berber]

Hi,

I was trying to build some package and it complained that libtool 1.4
was needed... looking at the version:

$ libtool --version
libtool (GNU libtool 1.3081 2009-02-17) 2.2.7a

Is it 1.3081 or 2.2.7a?

I see at gnu.org that the latest stable is 2.2.6a, so I suppose the one
in Cygwin (1.7) is the bleeding edge.  Any trick/idea on how to use it
with packages that expect something sane as version.
-- 
René Berber


--
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: Calling Cygwin to start a shellscript

[Brian Mathis]

On Fri, May 15, 2009 at 5:35 PM, Thomas Wiedmann  wrote:
> Hello,
>
> How can a shellscript be called from the Windows cmd console using Cygwin,
> i. e. by which command, options and arguments has Cygwin to be called to run
> a shellscript, e. g. myscript.sh?
>
> Thomas Wiedmann


What I have done is associate files with a .sh extension to run the
bash.exe file.  Works for me, but I'm not sure if it pulls in all the
environment variables - but I don't need them.

--
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/

Calling Cygwin to start a shellscript

[Thomas Wiedmann]

Hello,

How can a shellscript be called from the Windows cmd console using Cygwin, 
i. e. by which command, options and arguments has Cygwin to be called to run 
a shellscript, e. g. myscript.sh?


Thomas Wiedmann



--
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] [1.7] Updated: cygwin-1.7.0-48

[Corinna Vinschen]

Hi folks,


I just uploaded a new Cygwin 1.7 test release, 1.7.0-48.

The list with the changes related to the previous test release 1.7.0-47
is attached below.

===
IMPORTANT NOTE

This -48 test release comes with a couple of modifications which are
based around a change in mount point handling.  I strongly advise that
you update to the latest setup-1.7.exe, version number is 2.625, from
http://cygwin.com/setup-1.7.exe before installing this latest Cygwin
test release.
===

Cygwin 1.7 is a major jump from Cygwin 1.5.x.  The list with the changes
related to Cygwin 1.5.25 is part of the User's Guide now:
http://cygwin.com/1.7/cygwin-ug-net/ov-new1.7.html

===
If nothing goes overly wrong, the official 1.7.1 release goes public
within the next 6 weeks.
===

Just download http://cygwin.com/setup-1.7.exe and use that setup tool
to install Cygwin 1.7.  As usual, please report bugs and problems to
the mailing list cygwin AT cygwin DOT com.

We also have a new User's Guide for 1.7, which is currently located at
http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html

We also now have new API documentation
http://cygwin.com/1.7/cygwin-api/cygwin-api.html

And we have a new FAQ, though very likely not quite complete since
we still don't know what exactly *is* a FAQ related to Cygwin 1.7.
http://cygwin.com/1.7/faq/faq.html

Bug fixes and extensions to the documentation in the form of patches
to the source SGML files are much appreciated.  The SGML sources are
located in the CVS repository under the winsup/doc directory, for
example here:
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/doc/?cvsroot=src

Same goes for Cygwin patches in general, of course.

===
This is still a TEST release.  Don't use in critical production
environments.

Nevertheless I'd like to encourage everyone to give 1.7 a shot.  Due to
internal changes it is possible to install a 1.7 release in parallel to
a 1.5 release and even run 1.7 processes in parallel to 1.5 processes.

* The processes will not know about each other!  Any try to interact
* between 1.7-based and 1.5-based processes will lead to, at least, funny
* results.

To install a 1.7 release in parallel to a 1.5 release, all you have
to do is to choose another root directory (for instance: C:\cygwin-1.7)
in setup-1.7's "Choose Installation Directory" dialog.

* NOTE: Due to the way setup-1.7 works, you have to change the directory
* right the first time you visit this dialog!  If you pressed the "Next"
* button and then "Back" again, it's already too late and setup-1.7 will
* create a broken 1.7 install.  If you pressed "Next" by mistake, exit
* setup-1.7 and start it again.
===


What's new in contrast to 1.7.0-46
===

- Cygwin will now not only auto-generate the root directory mount point
  and the cygdrive prefix, it will also now auto-generate the good old
  "/usr/bin" and "/usr/lib" mount points.  There's no reason anymore to
  have these mount points in /etc/fstab.

- The root directory mount point is quite important.  If it's wrong, a
  lot of stuff will break.  Therefore, the root mount point requires an
  additional mount option in /etc/fstab, otherwise the /etc/fstab entry
  will be ignored.  For more details, read the new mount table documentation
  in http://cygwin.com/1.7/cygwin-ug-net/using.html#mount-table

- Cygwin will internally now always use the $LC_ALL/$LC_CTYPE/$LANG
  setting from the environment, regardless whether the application is
  locale-aware or not.  If the locale is not set in the environment,
  Cygwin will internally use UTF-8 for widechar<->multibyte conversion.
  This makes sure that Cygwin generates reproducible, identical filenames
  in interacting applications, whether or not they are locale-aware or not.

- The Cygwin console will also use the $LC_ALL/$LC_CTYPE/$LANG setting
  from the environment.  This drops the restriction that the console
  charset must be set at Console startup, introduced in early April.

- mkgroup and mkpasswd will now by default generate passwd and group
  entries in UTF-8, unless the environment contains a specific setting
  of $LC_ALL/$LC_CTYPE/$LANG.
  The same defaulting to UTF-8 output is used in cygpath, ldd, and passwd.

- Two changes in the `ps -W' output.  `ps -W' now prints all processes on
  the machine when running under an (elevated) administrator account,
  not only the processes in the current session.  It also now prints
  the name of 64 bit processes on 64 bit Windows, rather than just
  printing "*** unknown ***".


Bugfixes:
=

- Cygwin wil

Re: [1.7] Updated: {emacs,emacs-X11,emacs-el}-23.0.92-1

[Ken Brown]

On 5/15/2009 9:09 AM, gustav wrote:

Dear Ken,

First, thank you so much for having taken care of Emacs!

I enclose a patch to rmail.el, which I always have to apply, because
version 21.2 normally attempts to create files with "po:", but neither
Windows nor Cygwin tolerate that. Current rmail.el checks for Windows,
but doesn't for Cygwin.


This has already been fixed upstream, as of emacs 22.1.  Here's an 
excerpt from the current rmail.el (emacs 23.0.92):


(concat ".newmail-"
(file-name-nondirectory
 (if (memq system-type '(windows-nt cygwin ms-dos))
 ;; cannot have colons in file name
 (replace-regexp-in-string ":" "-" file)
   file)))

By the way, the patch is no longer needed; as of cygwin 1.7, it's legal 
to have colons in file names.


Ken

P.S.  For future reference, it's best to send comments about cygwin 
packages to the cygwin mailing list so that others can benefit from them 
also.


--
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] [1.7] Updated: {emacs,emacs-X11,emacs-el}-23.0.92-1

[Ken Brown]

New experimental versions of the emacs, emacs-X11, and emacs-el packages 
are now available for download for those testing cygwin 1.7, replacing 
the previous experimental 22.1-3 packages.  I have left 21.2-13 as current.


CYGWIN NEWS:

This is the first release in almost two years, after a maintainer 
change.  If no serious problems arise, I hope to make some version of 
emacs-23 the current version of emacs by the time Cygwin 1.7 is released.


There is one known bug: The cygwin build of emacs has problems getting 
the local time zone (see 
http://www.cygwin.com/ml/cygwin/2009-02/msg00148.html).  This affects 
emacs functions like display-time.  A workaround is to set the TZ 
environment variable before starting emacs.  For example,


  export TZ=America/New_York

NEWS:
=
This is an upstream pre-release for what will be emacs 23.1.  See

  http://www.gnu.org/software/emacs/

for more information.

DESCRIPTION:

Emacs is a powerful, customizable, self-documenting, modeless text 
editor.  Emacs contains special code editing features, a scripting 
language (elisp), and the capability to read mail, news, and more 
without leaving the editor.


Ken Brown
New emacs maintainer for Cygwin



To update your installation, click on the "Install Cygwin now" link
on the http://cygwin.com/ web page.  This downloads setup.exe to
your system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is
available starting at this URL.



--
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: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8

[Corinna Vinschen]

On May 15 20:34, IWAMURO Motonori wrote:
> 2009/5/15 Corinna Vinschen :
> > I have just trouble with SJIS, but that's not something I can easily
> > test. Maybe you can look into that in the next couple of days?
> 
> Maybe I can. Please explain details of the trouble.

Probably I only fall over my own feet.  I was surprised to see the
filenames using chinese characters (from Lenik's examples) using SO/UTF
sequences.  I didn't expect that, but maybe that was correct.  The whole
problem already starts with me not being able to see non-western chars
in the console window.  The two available console fonts simple don't
provide them, so I only see squares, even if the characters are printed
correctly.

It would be cool if you could simply use SJIS for testing and see if
everything looks basically ok.

For the records:  The internationalization stuff is a heck of a lot
of effort.  Even if my replies might sound mean sometimes, I'm glad
for your input and help coding.


Thanks,
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: [Fwd: [1.7] wcwidth failing configure tests]

[Corinna Vinschen]

On May 14 17:51, Jeff Johnston wrote:
> Corinna, I have no problem with checking the new patch in and extending  
> this later, assuming you have thoroughly tested this implementation.

I tested it with _MB_CAPABLE defined and with _MB_CAPABLE undefined.
Both variations worked as expected, the latter using the old newlib
implementation using iswprint/iswcntrl.

Patch applied.  I have adding the CJK variation on my todo list for
when I'm back from vacation.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
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: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8

[IWAMURO Motonori]

2009/5/15 Corinna Vinschen :
> I have just trouble with SJIS, but that's not something I can easily
> test. Maybe you can look into that in the next couple of days?

Maybe I can. Please explain details of the trouble.
-- 
IWAMURO Motnori 

--
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: [1.7] bug in printf and %ls

[Corinna Vinschen]

On May 15 13:49, Alexey Borzenkov wrote:
> On Fri, May 15, 2009 at 1:30 PM, Alexey Borzenkov  wrote:
> > And I found why. It appears that there's a bug in printf with %ls that
> > will refuse to print the string completely if the wide string for %ls
> > cannot be represented in current charset.
> 
> [...]
> 
> > Prints nothing, i.e. it doesn't print neither of single quotes.
> 
> So, as it seems printf on linux abort like that too, although it
> manages to print first single quote first. So the only remaining
> question is why newlib doesn't print the first single quote.

It's not using the Linux glibc implementation of printf, but the
FreeBSD implementation.  So there are differences to be expected.
Both variations work within specification, though.


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: Cygwin 1.7 setup question

[Corinna Vinschen]

On May 14 13:54, Karl M wrote:
> > From: corinna
> > It's not running scripts as administrators.none, it's running them as
> > user.users-primary-group. That's "None" for all local accounts.
> >
> Is this setup behavior expected to stay the same, or eventually run
> them as administrator.administrators? 

It does not run as administrator.administrators, but as
current_user.administrators *if* current_user is member of the
administrators group.

The current behaviour, that postinstall scripts are running under
current_user.current_users_primary_group, is unfortunate and, in my
opinion, is a bug, but I have not found a useful workaround for this
behaviour so far.  Anyway, I have this on my overlong todo list.


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: [1.7] bug in printf and %ls

[Corinna Vinschen]

On May 15 13:30, Alexey Borzenkov wrote:
> [...]
>  It appears that there's a bug in printf with %ls that
> will refuse to print the string completely if the wide string for %ls
> cannot be represented in current charset. It's interesting that
> sometimes it behaves differently. For example:
> 
> $ mkpasswd -C
> NDGAMES\aborzenkov:unused:11721:10513:U-NDGAMES\aborzenkov,*sidremoved*:/home/aborzenkov:/bin/bash
> $ mkgroup -C
> NDGAMES\
> 
> Notice that in the second case it somehow managed to print domain name
> and separator before failing.
> 
> Another example:
> 
> #include 
> #include 
> 
> int main(int argc, char** argv)
> {
>   setlocale(LC_ALL, "en_US.CP1252");
>   printf("'%ls'", L"\u0410\u0411\u0412");
>   return 0;
> }
> 
> Prints nothing, i.e. it doesn't print neither of single quotes. If it
> couldn't represent those characters, I think it should either ignore
> them, or try to display them with SO-UTF-8. Making printf call fail
> like that is, imho, really unexpected.

printf must not decide by itself over the charset to use for the widechar
to multibyte conversion.  If you run the same on Linux, you also get a
broken output.  It only manages to print the leading quoting char.  It
does not print the second quoting char, because the mbtowc conversion
failed.  If you check the return code of printf, you see why:

  if (printf("'%ls'xxx", L"\u0410\u0411\u0412") < 0)
perror ("\nprintf");

prints "printf: Invalid or incomplete multibyte or wide character"
on Linux as well as on Cygwin.

I'll change mkgroup and mkpasswd to call setlocale and to fall back to
UTF-8 if the locale is "C".


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: [1.7] bug in printf and %ls

[Alexey Borzenkov]

On Fri, May 15, 2009 at 1:30 PM, Alexey Borzenkov  wrote:
> And I found why. It appears that there's a bug in printf with %ls that
> will refuse to print the string completely if the wide string for %ls
> cannot be represented in current charset.

[...]

> Prints nothing, i.e. it doesn't print neither of single quotes.

So, as it seems printf on linux abort like that too, although it
manages to print first single quote first. So the only remaining
question is why newlib doesn't print the first single quote.

--
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: [1.7] mkpasswd and mkgroup ignore user and group names with national characters

[Corinna Vinschen]

On May 15 11:43, Alexey Borzenkov wrote:
> I'm in a domain at work and previously used mkpasswd -d and mkgroup -d
> to populate /etc/passwd and /etc/group files. Unfortunately, we mostly
> use Russian versions of Windows (especially on servers) here and most
> built-in user and group names (like Administrator, Domain Users, etc.)
> are localized. With cygwin 1.5 these names were successfully exported
> by mkpasswd/mkgroup, however with cygwin 1.7 all such usernames are
> silently ignored and don't appear in the output.
> 
> Since my primary group is "Domain Users" every time I execute
> cygwin.bat I see this:
> 
> Your group is currently "mkgroup".  This indicates that neither
> your gid nor your pgsid (primary group associated with your SID)
> is in /etc/group.
> 
> The /etc/group (and possibly /etc/passwd) files should be rebuilt.
> See the man pages for mkpasswd and mkgroup then, for example, run
> 
> mkpasswd -l [-d] > /etc/passwd
> mkgroup  -l [-d] > /etc/group
> 
> Note that the -d switch is necessary for domain users.
> 
> Is it some bug or was it a design decision?

It's missing setlcoale calls in the first place.  I'm going to fix that.


Thanks,
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: [1.7] bug in printf and %ls

[Alexey Borzenkov]

On Fri, May 15, 2009 at 11:43 AM, Alexey Borzenkov  wrote:
> I'm in a domain at work and previously used mkpasswd -d and mkgroup -d
> to populate /etc/passwd and /etc/group files. Unfortunately, we mostly
> use Russian versions of Windows (especially on servers) here and most
> built-in user and group names (like Administrator, Domain Users, etc.)
> are localized. With cygwin 1.5 these names were successfully exported
> by mkpasswd/mkgroup, however with cygwin 1.7 all such usernames are
> silently ignored and don't appear in the output.

And I found why. It appears that there's a bug in printf with %ls that
will refuse to print the string completely if the wide string for %ls
cannot be represented in current charset. It's interesting that
sometimes it behaves differently. For example:

$ mkpasswd -C
NDGAMES\aborzenkov:unused:11721:10513:U-NDGAMES\aborzenkov,*sidremoved*:/home/aborzenkov:/bin/bash
$ mkgroup -C
NDGAMES\

Notice that in the second case it somehow managed to print domain name
and separator before failing.

Another example:

#include 
#include 

int main(int argc, char** argv)
{
  setlocale(LC_ALL, "en_US.CP1252");
  printf("'%ls'", L"\u0410\u0411\u0412");
  return 0;
}

Prints nothing, i.e. it doesn't print neither of single quotes. If it
couldn't represent those characters, I think it should either ignore
them, or try to display them with SO-UTF-8. Making printf call fail
like that is, imho, really unexpected.

--
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/

[1.7] mkpasswd and mkgroup ignore user and group names with national characters

[Alexey Borzenkov]

I'm in a domain at work and previously used mkpasswd -d and mkgroup -d
to populate /etc/passwd and /etc/group files. Unfortunately, we mostly
use Russian versions of Windows (especially on servers) here and most
built-in user and group names (like Administrator, Domain Users, etc.)
are localized. With cygwin 1.5 these names were successfully exported
by mkpasswd/mkgroup, however with cygwin 1.7 all such usernames are
silently ignored and don't appear in the output.

Since my primary group is "Domain Users" every time I execute
cygwin.bat I see this:

Your group is currently "mkgroup".  This indicates that neither
your gid nor your pgsid (primary group associated with your SID)
is in /etc/group.

The /etc/group (and possibly /etc/passwd) files should be rebuilt.
See the man pages for mkpasswd and mkgroup then, for example, run

mkpasswd -l [-d] > /etc/passwd
mkgroup  -l [-d] > /etc/group

Note that the -d switch is necessary for domain users.

Is it some bug or was it a design decision?

--
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/