Re: cygwin beta packages
Yaakov Selkowitz writes: On 2014-11-10 12:31, Achim Gratz wrote: The current beta packages contain a . in the release number. That dot is chopped off along with the anything that follows in some places during install in setup.exe. Which places exactly? We could just fix this in setup instead. I haven't had time to really track this down, but the display of the currently installing package is one such place. I would suggest that a . should not be allowed in the release part of the PVR since otherwise it'll become very hard to parse or we need to have a list of possible suffixes that we can strip off before parsing. Whatever we do, it should be documented someplace other than an actual piece of code. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: cygwin beta packages
Corinna Vinschen writes: This only happens in genini AFAIK, not in upset. But the dependency issues might really be related to the test release version numbers. Yaakov is digging into upset ATM. OK, when I find time I'll have a look of how to fix it. BTW, is there a good reason to keep this lobotomy between upset and genini? In the long run I believe it might be easier to just have one tool. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: cygwin beta packages
On 11/11/2014 17:20, Achim Gratz wrote: Corinna Vinschen writes: This only happens in genini AFAIK, not in upset. But the dependency issues might really be related to the test release version numbers. Yaakov is digging into upset ATM. OK, when I find time I'll have a look of how to fix it. BTW, is there a good reason to keep this lobotomy between upset and genini? In the long run I believe it might be easier to just have one tool. You might want to start by taking a look at https://cygwin.com/ml/cygwin-apps/2007-02/msg00060.html
Re: cygwin beta packages
Jon TURNEY writes: You might want to start by taking a look at https://cygwin.com/ml/cygwin-apps/2007-02/msg00060.html If you were worried, I'm not gonna try Perl version objects on these... :-) Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
cygwin setup program questions
I have some elementary questions regarding the cygwin setup program. I ran the latest version 2.852 (64 bit). the options are install / re-install / un-install / default my understanding is as follows; choosing install creates a new installation of the selected cygwin components choosing re-install uninstalls the selected cygwin components, then creates a new installation choosing un-install uninstalls the selected cygwin components choosing default updates the selected cygwin components so if I wish to update my local installation to the latest release, I would choose default, as per the following screen capture; http://www.cpm86.com/default.jpg What is the function of the keep / cur / exp radio buttons? Please confirm my understanding of these four options. Thanks. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: RFC: 1.7.33 problem with user's home directory
On 11/11/2014 7:40 AM, Andrey Repin wrote: Greetings, Yaakov Selkowitz! In short, elusive benefits of having a separate cygwin-specific clean homes versus confusing disjoint of multiple places to look for single user's files, settings, and other stuff when it comes to backups and migrating profiles. This an extremely personal point of view. For me, I strongly hate mixing my cygwin home with standard windows one. I prefer to have separate cygwin home also between 32 and 64 bit WBR, Andrey Repin Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
2014-11-11 1:45 GMT+01:00 Andrey Repin: I see literally zero reason to maintain separate, cygwin-specific home directory. I think I have to disagree with you. When mixing MSYS, msysGit and Cygwin in the same home directory the dot-files can become a problem. Especially when it comes to line ending in those files and the line ending setting in .gitconfig. Regards, Frank -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 10 23:19, Warren Young wrote: On Nov 10, 2014, at 6:38 PM, Jeffrey Altman jalt...@secure-endpoints.com wrote: My personal preference would be for the Cygwin Home directory to be created under %HOMEPATH%\AppData\Roaming\Cygwin That’s certainly the way you’re *supposed* to do it on Windows. There’s some value in using %USERPROFILE% for this, however: 1. c:\Users\ShortName is directly analogous to /home/shortname on Linux or /Users/ShortName on OS X. 2. Recent versions of Windows have given up on the “My” prefix for the main directories within your user profile directory which happens to make them match the scheme used on Ubuntu, Fedora, OS X, etc. Finger memory like “cd ~/Desktop” will serve you better if Cygwin doesn’t bury the user directory underneath AppData somewhere. You can paper over #2 with symlinks, of course, as I already do while using the current c:\cygwin\home scheme. It would just be nice to avoid the need to create those symlinks. Symlinks don’t always behave exactly the same as real directories, for one thing. Use mount points in /etc/fstab or /etc/fstab.d. Mount points usually behave like real directories. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpD3Lq9B74QI.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 10 20:38, Jeffrey Altman wrote: On 11/10/2014 3:52 PM, Corinna Vinschen wrote: Hi, after a long discussion in RL today, I came to the conclusion that there's a major problem in the current handling of the user's home directory in AD environments in the new user account code when not using /etc/passwd files. My personal preference would be for the Cygwin Home directory to be created under %HOMEPATH%\AppData\Roaming\Cygwin That way the home directory is isolated from native windows applications that might use the same file names but with different line endings directly in %HOMEPATH%. And, the data is within the user profile so that when accessed via redirection or otherwise, the data is accessible on every machine the user logs into. I don't think that works as expected in all environments. What you refer to above is not, in fact, %HOMEPATH%\AppData\Roaming\Cygwin, but %USERPROFILE%\AppData\Roaming\Cygwin. %USERPROFILE% and %HOMEPATH% are two different things, maintained separately in AD. The roaming user profile is often not the same path as the homedir, it's just the lazy default. The roaming user profile is loaded from the profile server every time you log on to a machine. If you have a big Cygwin home dir, you don't want that to be part of your roaming profile and being loaded over the net at login time. The homedir is typically on a fileserver which just gets connected to your drive Z:. Please keep in mind that I'm talking about the Cygwin home dir not as a default value which can be overridden in /etc/passwd, but of a Cygwin home dir as returned by Cygwin when fetching the passwd entry from AD, and no passwd file exists. This Cygwin home dir should be: - Make some kind of sense when using a default value. - Be configurable by the administrators if possible. That's why I thought it a good idea to utilize unixHomeDirectory. Default is /home/$USER, The admins can set it to some other value in POSIX notation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp_oky6fEWJ7.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
Marco Atzeri wrote: On 11/11/2014 7:40 AM, Andrey Repin wrote: In short, elusive benefits of having a separate cygwin-specific clean homes versus confusing disjoint of multiple places to look for single user's files, settings, and other stuff when it comes to backups and migrating profiles. This an extremely personal point of view. For me, I strongly hate mixing my cygwin home with standard windows one. I prefer to have separate cygwin home also between 32 and 64 bit WBR, Audrey Repin Regards Marco Andrey has expressed his opinion on Cygwin's user home several times now. And I sincerely hope that it will not become the accepted view for the location of an user's home. Please, please, please, do NOT remove the possibility to maintain (the location of an user's home of) Cygwin as far away from Windows as possible ... (otherwise I will have another reason the stick to the passwd/group files) And my apology to Andrey for failing to maintain the appropriate threading. Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 10 23:09, Warren Young wrote: On Nov 10, 2014, at 1:52 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable… Use of AD implies some level of security consciousness. The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator. This answer I wrote on Stack Overflow is one way to solve the problem today: http://stackoverflow.com/questions/2180/ It might not be a bad idea if Cygwin started doing this sort of thing by default in the future. (Obviously for new installs only.) What I gather from the replies so far is this: - Nobody really cares for unixHomeDirectory. - Some want to use the Windows home folder. - Some want Cygwin to utilize the HOMEPATH dir. - Some want Cygwin to use always it's own /home and do everything else via symlinks or mount points. The problem so far is that I'm not sure it's clear to everybody what I mean. I'm *not* talking about a default value which can easily be overridden by tweaking /etc/passwd. I'm talking about what the passwd entry contains if there's no passwd file, and the admins want to keep the administration strictly inside AD. The passwd entry gets generated from what AD provides. And here we need a sensible default behaviour. One possible, but not naturally useful default behaviour is what the current code does: 1. Utilize the unixHomeDirectory AD attribute. 2. If unixHomeDirectory is empty, fall back to /home/$USER. Another possible behaviour: 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%). 2. If homeDirectory is empty, fall back to /home/$USER. Another: 1. Always use /home/$USER and let the admins come up with a matching mount point scheme. Another: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpM3S9HzTFaN.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
Corinna Vinschen corinna-cygwin at cygwin.com writes: One possible, but not naturally useful default behaviour is what the current code does: 1. Utilize the unixHomeDirectory AD attribute. 2. If unixHomeDirectory is empty, fall back to /home/$USER. [...] Default to /home/$USER unless a specific AD attribute is specified in some configuration file (maybe nsswitch.conf, maybe something else) and that attribute is non-empty. 1. Always use /home/$USER and let the admins come up with a matching mount point scheme. Would work for me, but then the configuration of those mount points would need to be directable somehow. Another: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. Looks good, but maybe allow the AD attribute to be explicitly named (e.g. cygwinHomeDirectory). For local accounts maybe some environment variable or registry key should be available as a configuration option. Regards, Achim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11 11:18, Corinna Vinschen wrote: On Nov 10 23:09, Warren Young wrote: On Nov 10, 2014, at 1:52 PM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable… Use of AD implies some level of security consciousness. The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator. This answer I wrote on Stack Overflow is one way to solve the problem today: http://stackoverflow.com/questions/2180/ It might not be a bad idea if Cygwin started doing this sort of thing by default in the future. (Obviously for new installs only.) What I gather from the replies so far is this: - Nobody really cares for unixHomeDirectory. - Some want to use the Windows home folder. - Some want Cygwin to utilize the HOMEPATH dir. - Some want Cygwin to use always it's own /home and do everything else via symlinks or mount points. The problem so far is that I'm not sure it's clear to everybody what I mean. I'm *not* talking about a default value which can easily be overridden by tweaking /etc/passwd. I'm talking about what the passwd entry contains if there's no passwd file, and the admins want to keep the administration strictly inside AD. The passwd entry gets generated from what AD provides. And here we need a sensible default behaviour. One possible, but not naturally useful default behaviour is what the current code does: 1. Utilize the unixHomeDirectory AD attribute. 2. If unixHomeDirectory is empty, fall back to /home/$USER. Another possible behaviour: 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%). 2. If homeDirectory is empty, fall back to /home/$USER. Another: 1. Always use /home/$USER and let the admins come up with a matching mount point scheme. Another: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. Another way to handle Cygwin-specific settings would be to utilize the description(*) field in the user's entry, just as implemented for SAM accounts. See the SAM part of https://cygwin.com/preliminary-ug/ntsec.html#ntsec-mapping-passwdinfo for how to use XML-alike entries in the description field to add user data, for instance cygwin home=/foo/bar\ shell=/bin/tcsh/ This could be added to some standard scheme: 1. Utilize the description attribute. 2. If description is empty, utilize homeDirectory. 3. If homeDirectory is empty, use /home/$USER. Or this could be added as a setting in nsswitch.conf: home: [unix|win|desc|home] I could think of arbitrarily complex ways to extend this nsswitch.conf setting, as in: home: /foo/bar/%U With %U being the Windows username, %D the domain name, %u the Cygwin user name. But all this also takes time to implement, of course :( Corinna (*) Note the naming confusion: The `net user /comment:...' command sets the AD attribute description. The `net user /usercomment:...' command sets the AD attribute comment. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp6aJ2OoBzj7.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11 11:05, Achim Gratz wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: One possible, but not naturally useful default behaviour is what the current code does: 1. Utilize the unixHomeDirectory AD attribute. 2. If unixHomeDirectory is empty, fall back to /home/$USER. [...] Default to /home/$USER unless a specific AD attribute is specified in some configuration file (maybe nsswitch.conf, maybe something else) and that attribute is non-empty. 1. Always use /home/$USER and let the admins come up with a matching mount point scheme. Would work for me, but then the configuration of those mount points would need to be directable somehow. Another: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. Looks good, but maybe allow the AD attribute to be explicitly named (e.g. cygwinHomeDirectory). Cygwin schema extension? :) For local accounts maybe some environment variable or registry key should be available as a configuration option. I'm not that concerned about SAM accounts. Typically they have no problem with /home/$USER anyway, and they have the SAM description field to add cygwin-specific data. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpE01c0ou7c2.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.33-0.6
On Nov 11 07:39, Christian Franke wrote:
Corinna Vinschen wrote:
On Nov 10 20:21, Christian Franke wrote:
What will be the behavior of the predecessor of e.g. the csih function
csih_create_unprivileged_user if called with USER without HOST prefix,
machine is inside of domain and the user does not exist:
- create local windows USER and require the config script to retrieve the
actual Cygwin HOST+USER name,
- fail and tell the calling config script to retry with HOST+USER instead
(if possible),
- create local windows USER and create a /etc/passwd entry to support a
non-prefixed Cygwin USER in this case,
- one of the above, selected by a new option.
I'm not exactly sure yet. I'm working on it, and I ripped apart the
functions dealing with this problem by handling the cygwin username and
the windows username separately. But it's not yet finished. In theory
you have two cases.
Either the account already exists, then the user should (probably
(grain/salt)) specify the Cygwin username, which is either prefixed or
not prefixed, dependent on the DB it will get taken from. The script
fetches the Windows domain and username from the U-... entry in pw_gecos
then.
Or the account doesn't exist, then the username is just a name. The
user account will be created in the local SAM and dependent on the state
of the machine, AD member or not, will be prefixed or not as Cygwin
account.
Something like that.
Possibly a two step process:
csih_check_unprivileged_user --allow-prefix $USER
if [ $csih_unpriv_cygwin_username != $USER ]; then
# Cygwin username has prefix
inform user, patch configuration file, ...
fu
csih_create_unprivileged_user [ $PASSWORD ]
I'm making the prefixing depend on the just running Cygwin version
right now, and then, if an nsswitch.conf file exists, whether the
setting is files-only or not.
Is there any compromise possible which lets mkpasswd generate the
forward compatible accounts by default? I made the change to mkpasswd
and mkgroup I outlined last week, but I deliberately didn't check it in
because I'm still hoping we find a compromise going forward. I
understand that in your scenario you will have to use /etc/passwd for a
while longer.
But... how many scripts would you really have to change if mkpasswd
generates prefixed names?
We could add 'sed' to /etc/passwd generating script, no problem.
Oh, cool!
The actual test scripts tools from this use case pass local usernames
from/to non-Cygwin programs and rely on the fact that Cygwin and Windows
username match.
For the long term, have some cyguser, cyggroup tools (similar to cygpath)
which convert the names would be helpful.
Feel free to provide them. I'm not quite sure what kind of conversion
you're thinking about. Cygwin-Windows? If so, you can get that
with simple scripts:
pwd_entry=$(/usr/bin/getent passwd $username)
# Extract Windows username and domain
tmp=${pwd_entry#*:*:*:*U-}
tmp=${pwd_entry%%,*}
domain=${tmp%\\*}
username=${tmp#*\\}
Alternatively, is setting some environment
variable feasible for tweaking the output of mkpasswd backward
compatible?
Of course, yes.
Or mkpasswd -l behavior depends on nsswitch.conf setting:
passwd only: Old behavior
passwd, db: New behavior, print warning
db only: fail
That's an interesting idea...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgp9at1hexRqe.pgp
Description: PGP signature
Re: Setup 2.774 texlive postinstall takes 10+ hours
On Nov 10 22:33, Yaakov Selkowitz wrote: On 2014-11-10 22:23, Yaakov Selkowitz wrote: Dependency order of packages: libgcc1 base-cygwin cygwin dash tzcode libstdc++6 terminfo sed gzip libpcre1 grep libreadline7 bash libncursesw10 [snip] Now that I think about it, regardless of libgcc1, that still doesn't make much sense. sed, grep, and bash depend on libintl8, which depends on libiconv2, and libreadline7 (which is required by bash) itself depends on libncursesw10, so that should be at least two places earlier. All of those dependencies are listed in setup.hint (and hence setup.ini), so is there something wrong with setup itself? What about dependency loops? AFAICS, coreutils depends on tzcode, tzcode depends on coreutils. Both depend on libgcc1. This introduces a big problem in dependency resolution because there's no unambiguous starting point. What if we remove the coretuls dep from tzcode. Or, actually, what if we make sure that Base packages only depend on libs, but never on any other Base package? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgptg4SqdKnM0.pgp Description: PGP signature
setup-x86.exe gives a 134 exit code installing libgvc6
Good evening: I recently ran the latest setup-x86.exe to pick up the recent updates for my Windows XP (SP3) system. I received the following error message. Package: libgvc6 libgvc6.sh exit code 134 From what I can tell, this means the installation process received a SIGABORT signal during the installation. I've seen some other discussions which say this can be caused by missing files (dependencies???) attempting to be executed. I could be barking up the wrong tree on that score though. I've attached the output of the cygcheck -svr command for analysis if that helps. I noticed the output says libserf0_1 is incomplete. When I try to reinstall it, my only choices are uninstall and keep; reinstall is not an option. Brian S. Wilson -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
One big vote for the '/etc/nsswitch.conf' idea. I think the truth of the matter is that enterprise environments are way too dynamic (and inconsistent) to attempt to satisfy the majority of configurations with any particular default ordering assumption. Another user brought up a good point about desire for Cygwin to operate in 'read-only' mode -- something that I'd also really love to see addressed. The need for /tmp and /var/log to be 'writable' results in some problems in a high-security environments. This became especially noticeable with Cygwin 64-bit because Windows does not automatically redirect write attempts to %LOCALAPPDATA%\VirtualStore. Anyhow, that's probably left to a different conversation for a different day... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11 07:11, Bryan Berns wrote: One big vote for the '/etc/nsswitch.conf' idea. I think the truth of the matter is that enterprise environments are way too dynamic (and inconsistent) to attempt to satisfy the majority of configurations with any particular default ordering assumption. Another user brought up a good point about desire for Cygwin to operate in 'read-only' mode -- something that I'd also really love to see addressed. The need for /tmp and /var/log to be 'writable' results in some problems in a high-security environments. This can be easily fixed by providing matching mount points in /etc/fstab or /etc/fstab.d. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp_pq9xIARQW.pgp Description: PGP signature
RE: RFC: 1.7.33 problem with user's home directory
Another: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. Looks good, but maybe allow the AD attribute to be explicitly named (e.g. cygwinHomeDirectory). Cygwin schema extension? :) Sorry to join in the fun here so late, but I like the current behavior and really don't see any reason (given my usage) why I'd want to mix my cygwin and windows files together in the same directory. Additionally, I don't have the ability to change the unixHomeDirectory field in our AD. I also like having everything stored under one main directory (c:\cygwin) for ease of backup and ease of identification of all cygwin-involved files for our virus and our application whitelisting systems. As I result, if folks feel that something must be done, I like the plan above. I don't really care what the default behavior is, so long as the home: home option is available. Dave
Re: RFC: 1.7.33 problem with user's home directory
On 11/11/2014 4:59 AM, Corinna Vinschen wrote: Please keep in mind that I'm talking about the Cygwin home dir not as a default value which can be overridden in /etc/passwd, but of a Cygwin home dir as returned by Cygwin when fetching the passwd entry from AD, and no passwd file exists. This Cygwin home dir should be: - Make some kind of sense when using a default value. - Be configurable by the administrators if possible. That's why I thought it a good idea to utilize unixHomeDirectory. Default is /home/$USER, The admins can set it to some other value in POSIX notation. Using the unixHomeDirectory feels wrong to me because it doesn't provide a context to indicate where the home directory is located. Its intended purpose is to permit the specification of the home directory for UNIX systems. On a UNIX system it might be a local disk or /home might be on one or more network file systems which might or might not be accessible from a Windows system. What would the behavior be if unixHomeDirectory was /afs/example.edu/users/j/e/jeff and no AFS client was installed on the Windows system? What would the behavior be if there was an AFS client installed on the Windows system? To access AFS from Windows would require UNC notation not an absolute root. Does a default location in the Windows profile make sense and permit administrators to provide HKCU\SOFTWARE\Cygwin\ registry value to indicate an alternative location? Or perhaps a per-user environment variable which would also be distributed via the user's registry hive. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: Setup 2.774 texlive postinstall takes 10+ hours
On 11/11/2014 6:53 AM, Corinna Vinschen wrote: On Nov 10 22:33, Yaakov Selkowitz wrote: On 2014-11-10 22:23, Yaakov Selkowitz wrote: Dependency order of packages: libgcc1 base-cygwin cygwin dash tzcode libstdc++6 terminfo sed gzip libpcre1 grep libreadline7 bash libncursesw10 [snip] Now that I think about it, regardless of libgcc1, that still doesn't make much sense. sed, grep, and bash depend on libintl8, which depends on libiconv2, and libreadline7 (which is required by bash) itself depends on libncursesw10, so that should be at least two places earlier. All of those dependencies are listed in setup.hint (and hence setup.ini), so is there something wrong with setup itself? What about dependency loops? AFAICS, coreutils depends on tzcode, tzcode depends on coreutils. Both depend on libgcc1. This introduces a big problem in dependency resolution because there's no unambiguous starting point. What if we remove the coretuls dep from tzcode. Or, actually, what if we make sure that Base packages only depend on libs, but never on any other Base package? Except that all Base packages (other than base-cygwin) should depend on base-cygwin. That will guarantee that base-cygwin precedes all other Base packages in the dependency order. And if we make _autorebase depend on nothing, then we're guaranteed that it precedes anything that depends on it. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Setup 2.774 texlive postinstall takes 10+ hours
On 11/11/2014 9:14 AM, Ken Brown wrote: On 11/11/2014 6:53 AM, Corinna Vinschen wrote: On Nov 10 22:33, Yaakov Selkowitz wrote: On 2014-11-10 22:23, Yaakov Selkowitz wrote: Dependency order of packages: libgcc1 base-cygwin cygwin dash tzcode libstdc++6 terminfo sed gzip libpcre1 grep libreadline7 bash libncursesw10 [snip] Now that I think about it, regardless of libgcc1, that still doesn't make much sense. sed, grep, and bash depend on libintl8, which depends on libiconv2, and libreadline7 (which is required by bash) itself depends on libncursesw10, so that should be at least two places earlier. All of those dependencies are listed in setup.hint (and hence setup.ini), so is there something wrong with setup itself? What about dependency loops? AFAICS, coreutils depends on tzcode, tzcode depends on coreutils. Both depend on libgcc1. This introduces a big problem in dependency resolution because there's no unambiguous starting point. What if we remove the coretuls dep from tzcode. Or, actually, what if we make sure that Base packages only depend on libs, but never on any other Base package? Except that all Base packages (other than base-cygwin) should depend on base-cygwin. That will guarantee that base-cygwin precedes all other Base packages in the dependency order. And if we make _autorebase depend on nothing, then we're guaranteed that it precedes anything that depends on it. Of course, this still doesn't solve the problem of making sure that the _autorebase postinstall script runs whenever the user installs a package containing DLLs. I wonder if we should reconsider Achim's proposal. If I understand correctly, it is something like this (oversimplified): 1. Change autorebase.bat to do an incremental rebase instead of trying to do a full rebase. 2. Arrange for autorebase.bat to never be marked as done. Achim, please correct me if my oversimplification distorts your suggestion too much. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Frank Fesevur! I see literally zero reason to maintain separate, cygwin-specific home directory. I think I have to disagree with you. When mixing MSYS, msysGit and Cygwin in the same home directory the dot-files can become a problem. Especially when it comes to line ending in those files and the line ending setting in .gitconfig. I think, the number of people mixing these things is lower than number of people using Cygwin with roaming profiles. And they know what they are doing, by definition. -- WBR, Andrey Repin (anrdae...@yandex.ru) 11.11.2014, 18:05 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable… Use of AD implies some level of security consciousness. The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator. This answer I wrote on Stack Overflow is one way to solve the problem today: http://stackoverflow.com/questions/2180/ It might not be a bad idea if Cygwin started doing this sort of thing by default in the future. (Obviously for new installs only.) What I gather from the replies so far is this: - Nobody really cares for unixHomeDirectory. As I understand it from replies, it's not nobody care, it's this is wrong way of doing it. - Some want to use the Windows home folder. - Some want Cygwin to utilize the HOMEPATH dir. When you clarify your question, this seems to be the same point. - Some want Cygwin to use always it's own /home and do everything else via symlinks or mount points. The problem so far is that I'm not sure it's clear to everybody what I mean. I'm *not* talking about a default value which can easily be overridden by tweaking /etc/passwd. I'm talking about what the passwd entry contains if there's no passwd file, and the admins want to keep the administration strictly inside AD. The passwd entry gets generated from what AD provides. And here we need a sensible default behaviour. Yes, this makes more sense. One possible, but not naturally useful default behaviour is what the current code does: 1. Utilize the unixHomeDirectory AD attribute. 2. If unixHomeDirectory is empty, fall back to /home/$USER. As has been pointed out, unixHomeDirectory is to tell *NIX system, where o look for user's homedir. Cygwin is not a a Unix system, and I have to agree that using this attribute for Cygwin wouldn't be the right thing. Another possible behaviour: 1. Utilize the homeDirectory AD attribute (aka %HOMEDRIVE%%HOMEPATH%). 2. If homeDirectory is empty, fall back to /home/$USER. Another: 1. Always use /home/$USER and let the admins come up with a matching mount point scheme. Another: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. How about a slight modification to this? nsswitch.conf configurable settings: user: Use %AppData%/Cygwin%PLATFORM% (Separate directory for different platform Cygwins) system: Use homeDirectory AD attribute. cygwin: Use current Cygwin way of /home/$USERNAME. Default setting is up to discussion. This is more clear in my opinon, than unix or win (Cygwin is not unix/linux, neither it's windows - it's a userspace DLL providing POSIX API compatibility in Windows), and definitely more clear, than home: home. -- WBR, Andrey Repin (anrdae...@yandex.ru) 11.11.2014, 18:18 Sorry for my terrible english...
Re: Setup 2.774 texlive postinstall takes 10+ hours
On Nov 11 10:02, Ken Brown wrote: On 11/11/2014 9:14 AM, Ken Brown wrote: On 11/11/2014 6:53 AM, Corinna Vinschen wrote: On Nov 10 22:33, Yaakov Selkowitz wrote: On 2014-11-10 22:23, Yaakov Selkowitz wrote: Dependency order of packages: libgcc1 base-cygwin cygwin dash tzcode libstdc++6 terminfo sed gzip libpcre1 grep libreadline7 bash libncursesw10 [snip] Now that I think about it, regardless of libgcc1, that still doesn't make much sense. sed, grep, and bash depend on libintl8, which depends on libiconv2, and libreadline7 (which is required by bash) itself depends on libncursesw10, so that should be at least two places earlier. All of those dependencies are listed in setup.hint (and hence setup.ini), so is there something wrong with setup itself? What about dependency loops? AFAICS, coreutils depends on tzcode, tzcode depends on coreutils. Both depend on libgcc1. This introduces a big problem in dependency resolution because there's no unambiguous starting point. What if we remove the coretuls dep from tzcode. Or, actually, what if we make sure that Base packages only depend on libs, but never on any other Base package? Except that all Base packages (other than base-cygwin) should depend on base-cygwin. That will guarantee that base-cygwin precedes all other Base packages in the dependency order. In theory that should be solved by the dependency to cygwin. Cygwin depends on base-cygwin, all other packages depend on cygwin. The problem is just that dependency loops can break that. And if we make _autorebase depend on nothing, then we're guaranteed that it precedes anything that depends on it. Per its setup.hint file it depends on nothing, just like base-cygwin, and both packages request that they don't get an automatic dependency to cygwin added. Of course, this still doesn't solve the problem of making sure that the _autorebase postinstall script runs whenever the user installs a package containing DLLs. I wonder if we should reconsider Achim's proposal. If I understand correctly, it is something like this (oversimplified): 1. Change autorebase.bat to do an incremental rebase instead of trying to do a full rebase. 2. Arrange for autorebase.bat to never be marked as done. Achim, please correct me if my oversimplification distorts your suggestion too much. Achim, can you give a management summary how your proposal works? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpV82pjLryh6.pgp Description: PGP signature
RE: how to embed shell script within a .BAT file
From: Achim Gratz Nellis, Kenneth writes: Jeremy's solution is closest to what I was looking for; however I need it to work from a networked, non-drive-mapped folder. (CMD.EXE doesn't like UNC paths.) I hadn't realized that I could pipe a script into bash. The solution to the UNC path problem is to put something PUSHD %~dp0 near the beginning of the script. That is if you really want to have .bat files and click on them in Explorer. Associating the shell scripts properly so that Explorer will hand them to Cygwin sounds like a better solution to me. BTW, works great! Here's the completed .BAT file preface with added error handling so the CMD window doesn't auto-close if the bash code exits with an error. @echo off set PATH=C:\cygwin64\bin;%PATH% PUSHD %~dp0 type %0 | sed 0,/^---BASH SCRIPT FOLLOWS---/ d; s/\r*$// | bash if errorlevel 1 pause exit ---BASH SCRIPT FOLLOWS--- ... I'll pursue associating a shell script with a file type when I have more time. --Ken Nellis -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11 08:51, Jeffrey Altman wrote: On 11/11/2014 4:59 AM, Corinna Vinschen wrote: Please keep in mind that I'm talking about the Cygwin home dir not as a default value which can be overridden in /etc/passwd, but of a Cygwin home dir as returned by Cygwin when fetching the passwd entry from AD, and no passwd file exists. This Cygwin home dir should be: - Make some kind of sense when using a default value. - Be configurable by the administrators if possible. That's why I thought it a good idea to utilize unixHomeDirectory. Default is /home/$USER, The admins can set it to some other value in POSIX notation. Using the unixHomeDirectory feels wrong to me because it doesn't provide a context to indicate where the home directory is located. That's why I started this discussion in the first place. It seemed like a good idea at the time, but not so anymore. Does a default location in the Windows profile make sense and permit administrators to provide HKCU\SOFTWARE\Cygwin\ registry value to indicate an alternative location? Or perhaps a per-user environment variable which would also be distributed via the user's registry hive. I'd prefer an admin-provided /etc/nsswitch.conf setting over registry or environment... :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpqwUvBS41GK.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
Corinna Vinschen writes: Looks good, but maybe allow the AD attribute to be explicitly named (e.g. cygwinHomeDirectory). Cygwin schema extension? :) I don't see why not, given that there's the possibility of having different information for Windows, Cygwin and UNIX in the same AD. But more realistically, one of the extensionAttributes that Exchange plugs in anyway could keep that information. For local accounts maybe some environment variable or registry key should be available as a configuration option. I'm not that concerned about SAM accounts. Typically they have no problem with /home/$USER anyway, and they have the SAM description field to add cygwin-specific data. OK. We'll find out soon enough how to set up a local sshd account anyway. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11 17:44, Achim Gratz wrote: Corinna Vinschen writes: Looks good, but maybe allow the AD attribute to be explicitly named (e.g. cygwinHomeDirectory). Cygwin schema extension? :) I don't see why not, given that there's the possibility of having different information for Windows, Cygwin and UNIX in the same AD. It's a bit complicated. You need a way to distinguish the name of an attribute from simple values like home, or cygwin as Andrey proposes. My simply Cygwin-internal LDAP interface has no way of providing arbitrary attribute strings either, so that needs to be extended first. Microsoft themselves use XML strings in some attribute blobs for TS settings and stuff, so maybe the description field should be sufficient. I'm wondering if we really need other attributes then. But more realistically, one of the extensionAttributes that Exchange plugs in anyway could keep that information. I have no experience with Exchange, so I can't tell. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp1b_QUfvNgV.pgp Description: PGP signature
Re: RFC: 1.7.33 problem with user's home directory
On Nov 11 18:29, Andrey Repin wrote: Greetings, Corinna Vinschen! Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable… Use of AD implies some level of security consciousness. The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator. This answer I wrote on Stack Overflow is one way to solve the problem today: http://stackoverflow.com/questions/2180/ It might not be a bad idea if Cygwin started doing this sort of thing by default in the future. (Obviously for new installs only.) What I gather from the replies so far is this: - Nobody really cares for unixHomeDirectory. As I understand it from replies, it's not nobody care, it's this is wrong way of doing it. It's not the wrong thing if it's not used for anything else in a company. Another: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. How about a slight modification to this? nsswitch.conf configurable settings: user: Use %AppData%/Cygwin%PLATFORM% (Separate directory for different platform Cygwins) I really don't like this one. Your naming scheme (user/system/cygwin) has its merits, but I don't see that a home directory of any sort belongs under AppData. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpe5rLtu3FOg.pgp Description: PGP signature
Re: Setup 2.774 texlive postinstall takes 10+ hours
Corinna Vinschen writes: On Nov 11 10:02, Ken Brown wrote: Of course, this still doesn't solve the problem of making sure that the _autorebase postinstall script runs whenever the user installs a package containing DLLs. I wonder if we should reconsider Achim's proposal. If I understand correctly, it is something like this (oversimplified): 1. Change autorebase.bat to do an incremental rebase instead of trying to do a full rebase. 2. Arrange for autorebase.bat to never be marked as done. Achim, please correct me if my oversimplification distorts your suggestion too much. Achim, can you give a management summary how your proposal works? As Ken already correctly summarized, the autorebase postinstall script will never be marked as done by setup.exe, so it will be run on each install or update. The incremental part ensures that this step doesn't take too much time if there's nothing to do. Currently this is based on the name of that script, but it could be done differently. The other part is that all perpetual postinstall scripts are run before any normal postinstall scripts, so these can assume to run in a correctly rebased environment. A slightly modified variant of the same mechanism could be used for those infodir, icon cache and fontconfig updates, which should probably be run after the normal postinstall scripts. I think I've sent Ken a sketch doing this from within a postinstall script for the texlive packages, but providing some support from setup.ini and setup.exe for stratified postinstalls (pre-post and post-post :-) would make this much more robust. I haven't yet coded up anything in that direction, though. If you're wondering what happens when you've just installed a fresh Cygwin: the perpetual rebase postinstall scripts detects the situation and bails out, while the normal postinstall script does the initial rebase (and is marked done). Which means we have to fix the dependency problem anyway. Incremental autorebase packages and patched setup.exe available on request. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Can't Run Excel From A Cron Job Under Windows 7
I am trying to port a cygwin application that uses cron from a WinXP PC to a Win7 Pro PC and I find some cron jobs won't run. Specifically, I need to run an Excel program from a cron job and this doesn't work on my Win7 PC. In order to run an Excel program from cygwin I have this run.excel bash script with an embedded VB script that executes an Excel program: excel=$1 vbscript=/usr/tmp/$$.vbs cat -! $vbscript Dim xlApp Set xlApp = CreateObject(Excel.application) Set xlWb = xlApp.workbooks.Open($excel) xlApp.Quit Set xlWb = Nothing Set xlApp = Nothing ! chmod 777 $vbscript c:/Windows/System32/wscript.exe 'c:\cygwin64\usr\tmp\$$.vbs' An excel program is run like this: run.excel 'c:\Shared\Bin\Create_Daily_Scorecard.xls' When I run an Excel program interactively with this run.excel script it runs just fine but when I run it via a cron job Excel just hangs. When Excel hangs I can look at the processes running on the PC using the Windows Task Manager and I don't see the EXCEL.EXE process. But when I check the option to show processes from all users I see the hung EXCEL.EXE process, AND the user name displayed is my login. So I am running this under the Upar2 login and Task Manager doesn't display EXCEL.EXE as a Upar2 process but when I check 'Show processes from all users' it shows EXCEL.EXE running under user name Upar2 - a contradiction. What I suspect is happening is Excel is attempting to do something that requires Upar2 permission but it isn't really running as Upar2 so Excel displays some error message and is waiting for the user to respond. But Excel is running invisibly so this can't be seen. I also suspect this Upar2 confusion isn't limited to running an Excel program. I can run a cron job with regular UNIX commands (cut, sort, etc) and see they are running with the ps command. But when I try to kill them (kill -9) I get permission denied. If I want to kill a process running via the cron I have to start cygwin with 'Run as administrator' and then I can kill processes running under the cron. So, does anyone know what's going on here and what I need to do get these cron jobs running. As I noted at the beginning this is being ported from WinXP, where all this works fine, to Win7. I set up cron using cron-config like this: $ cron-config Do you want to install the cron daemon as a service? (yes/no) yes Enter the value of CYGWIN for the daemon: [ ] Do you want the cron daemon to run as yourself? (yes/no) yes Please enter the password for user 'Upar2': Reenter: Running cron_diagnose ... ... no problem found. Do you want to start the cron daemon as a service now? (yes/no) yes OK. The cron daemon is now running. Denis cygcheck.out Description: cygcheck.out -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Setup 2.774 texlive postinstall takes 10+ hours
On Nov 11 18:08, Achim Gratz wrote: Corinna Vinschen writes: On Nov 11 10:02, Ken Brown wrote: Of course, this still doesn't solve the problem of making sure that the _autorebase postinstall script runs whenever the user installs a package containing DLLs. I wonder if we should reconsider Achim's proposal. If I understand correctly, it is something like this (oversimplified): 1. Change autorebase.bat to do an incremental rebase instead of trying to do a full rebase. 2. Arrange for autorebase.bat to never be marked as done. Achim, please correct me if my oversimplification distorts your suggestion too much. Achim, can you give a management summary how your proposal works? As Ken already correctly summarized, the autorebase postinstall script will never be marked as done by setup.exe, so it will be run on each install or update. The incremental part ensures that this step doesn't take too much time if there's nothing to do. Currently this is based on the name of that script, but it could be done differently. The other part is that all perpetual postinstall scripts are run before any normal postinstall scripts, so these can assume to run in a correctly rebased environment. I understand that you're patching setup to recognize the autorebase package by name, but how does it recognize other perpetual postinstall scripts ATM? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpS6O9Opd8Dw.pgp Description: PGP signature
Re: Setup 2.774 texlive postinstall takes 10+ hours
Corinna Vinschen writes: I understand that you're patching setup to recognize the autorebase package by name, but how does it recognize other perpetual postinstall scripts ATM? I actually match an _always suffix before the file extension. So once such a file gets installed in /etc/postinstall, it effectively becomes a perpetual postinstall script. Not the most elegant way of doing it, but since I needed to carry that patch for setup.exe locally I didn't want to make it much more complicated, especially nothing that would require extra features in setup.ini. We can think about something else if this is meant to become official. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
libssh2 update info. legitimate?
Hello, I noticed there was an update to libssh uploaded yesterday (11/10/14): https://cygwin.com/packages/x86/libssh2_1/ I don't see anything about an update to this in the announcements section. I also tried searching the site and can't find anything about an update to libssh. Can someone please confirm if this is a good update to install? Thanks in advance Mike -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can't Run Excel From A Cron Job Under Windows 7
Greetings, Kertz, Denis (D)** CTR **! I am trying to port a cygwin application that uses cron from a WinXP PC to a Win7 Pro PC and I find some cron jobs won't run. Specifically, I need to run an Excel program from a cron job and this doesn't work on my Win7 PC. In order to run an Excel program from cygwin I have this run.excel bash script with an embedded VB script that executes an Excel program: excel=$1 vbscript=/usr/tmp/$$.vbs cat -! $vbscript Dim xlApp Set xlApp = CreateObject(Excel.application) Set xlWb = xlApp.workbooks.Open($excel) xlApp.Quit Set xlWb = Nothing Set xlApp = Nothing ! chmod 777 $vbscript c:/Windows/System32/wscript.exe 'c:\cygwin64\usr\tmp\$$.vbs' An excel program is run like this: run.excel 'c:\Shared\Bin\Create_Daily_Scorecard.xls' When I run an Excel program interactively with this run.excel script it runs just fine but when I run it via a cron job Excel just hangs. Define runs fine please? What exactly that excel script is doing? When Excel hangs I can look at the processes running on the PC using the Windows Task Manager and I don't see the EXCEL.EXE process. But when I check the option to show processes from all users I see the hung EXCEL.EXE process, AND the user name displayed is my login. So I am running this under the Upar2 login and Task Manager doesn't display EXCEL.EXE as a Upar2 process but when I check 'Show processes from all users' it shows EXCEL.EXE running under user name Upar2 - a contradiction. Task manager display processes started in your current session. Not processes started under your credentials. That's an important difference. What I suspect is happening is Excel is attempting to do something that requires Upar2 permission but it isn't really running as Upar2 so Excel displays some error message and is waiting for the user to respond. But Excel is running invisibly so this can't be seen. More like you expect to run Excel interactively from service. Not possible. Period. I also suspect this Upar2 confusion isn't limited to running an Excel program. I can run a cron job with regular UNIX commands (cut, sort, etc) and see they are running with the ps command. But when I try to kill them (kill -9) I get permission denied. If I want to kill a process running via the cron I have to start cygwin with 'Run as administrator' and then I can kill processes running under the cron. Of course. -- WBR, Andrey Repin (anrdae...@yandex.ru) 11.11.2014, 22:14 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: how to embed shell script within a .BAT file
Greetings, Nellis, Kenneth! From: Achim Gratz Nellis, Kenneth writes: Jeremy's solution is closest to what I was looking for; however I need it to work from a networked, non-drive-mapped folder. (CMD.EXE doesn't like UNC paths.) I hadn't realized that I could pipe a script into bash. The solution to the UNC path problem is to put something PUSHD %~dp0 near the beginning of the script. That is if you really want to have .bat files and click on them in Explorer. Associating the shell scripts properly so that Explorer will hand them to Cygwin sounds like a better solution to me. BTW, works great! Here's the completed .BAT file preface with added error handling so the CMD window doesn't auto-close if the bash code exits with an error. @echo off set PATH=C:\cygwin64\bin;%PATH% PUSHD %~dp0 PUSHD %~dp0 But be aware, that you will lose the ability to run such script from different CWD. type %0 | sed 0,/^---BASH SCRIPT FOLLOWS---/ d; s/\r*$// | bash sed 0,/^---BASH SCRIPT FOLLOWS---/ d; s/\r*$// %~f0 | bash if errorlevel 1 pause exit That's nice for desktop application. But EXIT %ERRORLEVEL% would be more useful in general. And keep in mind: not everything can be run that way, unfortunately. Only interpreters accepting command stream from STDIN (such as bash). And you will lose the ability to pipe data to such script yourself. ---BASH SCRIPT FOLLOWS--- ... I'll pursue associating a shell script with a file type when I have more time. On a slightly unrelated note, please avoid naming your scripts .bat, when you are using extended CMD features. Not every .bat file interpreter supports a full range of bugs in CMD. -- WBR, Andrey Repin (anrdae...@yandex.ru) 11.11.2014, 22:35 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[Packaging error] docbook-utils-0.6.14-2; 32 and 64bit
Hi Files from /usr/doc/html/docbook-utils-0.6.14/ should probably be installed into /usr/share/doc/html/docbook-utils Ciao Volker -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[Packaging error] sitecopy-0.16.6-1; 32 and 64bit
Hi Files from /usr/doc/sitecopy should be installed under /usr/share/doc/sitecopy Ciao Volker -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! Shall the db entries utilize the Windows home folder if it exits(*) and drop using the unixHomeDirectory? It seems inevitable… Use of AD implies some level of security consciousness. The ability to write to c:\cygwin — not just during installation, but during all use thereafter! — comes out of a world where every user is a local Administrator. This answer I wrote on Stack Overflow is one way to solve the problem today: http://stackoverflow.com/questions/2180/ It might not be a bad idea if Cygwin started doing this sort of thing by default in the future. (Obviously for new installs only.) What I gather from the replies so far is this: - Nobody really cares for unixHomeDirectory. As I understand it from replies, it's not nobody care, it's this is wrong way of doing it. It's not the wrong thing if it's not used for anything else in a company. I would step away from any possible if's as much as... possible in such case. Another: 1. Add a setting to /etc/nsswitch.conf which allows to specify one of the above: home: [unix|win|home]... - unix means, set pw_dir to unixHomeDirectory - win means, set pw_dir to homeDirectory - home means, set pw_dir to /home/$USER - Multiple entries are possible. - Default in the absence of this setting is: always set pw_dir to /home/$USER. How about a slight modification to this? nsswitch.conf configurable settings: user: Use %AppData%/Cygwin%PLATFORM% (Separate directory for different platform Cygwins) I really don't like this one. I'm just summing up suggestions that have been raised in the list for last day. :) Your naming scheme (user/system/cygwin) has its merits, but I don't see that a home directory of any sort belongs under AppData. Not home directory. User profile directory. https://cygwin.com/ml/cygwin/2014-11/msg00201.html %AppData%/Cygwin == %HOMEPATH%/AppData/Roaming/Cygwin From corporate environment point of view, Cygwin is an application like every other one, and expected to behave according to environment standards, not invent its own. Windows environment standard dictates, that if an application intend to store large amount of user-specific files, it should do so uder %AppData%, or %LocalAppData% for discardable or hardware-specific environment. -- WBR, Andrey Repin (anrdae...@yandex.ru) 11.11.2014, 23:01 Sorry for my terrible english...
gnutls-3.2.20 doesn't compile anymore, probably conficting with installed libopts-devel
Hi Older gnutls versions compiled fine with cygwin. Latest versions come with their own libopts source tree, which is newer than the latest cygwin version. I get the following error when trying to compile gnutls-3.2.20 In file included from srptool-args.c:43:0: srptool-args.h:61:3: error: #error option template version mismatches autoopts/options.h header # error option template version mismatches autoopts/options.h header ^ srptool-args.h:62:3: error: unknown type name 'Choke' Choke Me Can we get a newer autogen package ? Ciao Volker -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gnutls-3.2.20 doesn't compile anymore, probably conficting with installed libopts-devel
On 2014-11-11 14:44, Dr. Volker Zell wrote: Older gnutls versions compiled fine with cygwin. Latest versions come with their own libopts source tree, which is newer than the latest cygwin version. I get the following error when trying to compile gnutls-3.2.20 In file included from srptool-args.c:43:0: srptool-args.h:61:3: error: #error option template version mismatches autoopts/options.h header # error option template version mismatches autoopts/options.h header ^ srptool-args.h:62:3: error: unknown type name 'Choke' Choke Me I cannot reproduce this. Do you have both autogen and libopts-devel installed? Also, are you using the autogen VPATH patch: http://sourceforge.net/p/cygwin-ports/gnutls/ci/master/tree/3.2.18-autogen-vpath.patch Can we get a newer autogen package ? I can do that, but that's not the problem here. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Latex font problem
This is discussed in the texlive release announcement https://cygwin.com/ml/cygwin-announce/2014-07/msg0.html under the heading Fontconfig. See also https://cygwin.com/ml/cygwin-xfree/2014-05/msg00020.html Yaakov, could we get a fontconfig update that fixes this? Thanks. Ken Having read that post and already seen the discussion about the Windows fonts folder I can understand that it should not be the responsibility of fontconfig to include (and by implication keep up to date) the latex fonts. Maybe I could suggest the texlive-collection-* packages add the appropriate folder in a file/symlinked file in /etc/fonts/conf.d as well as calling fc-cache, then the responsibility is clearly placed on one (collection of) package(s) to do this. Anyway, I'm sure you have better ideas, how to deal with this than I, so we'll add the workaround to our documentation build instructions. Thanks for the info. Phil -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Latex font problem
On 11/11/2014 4:31 PM, phil rosenberg wrote: This is discussed in the texlive release announcement https://cygwin.com/ml/cygwin-announce/2014-07/msg0.html under the heading Fontconfig. See also https://cygwin.com/ml/cygwin-xfree/2014-05/msg00020.html Yaakov, could we get a fontconfig update that fixes this? Thanks. Ken Having read that post and already seen the discussion about the Windows fonts folder I can understand that it should not be the responsibility of fontconfig to include (and by implication keep up to date) the latex fonts. The situation with the Windows fonts folder is completely different. It's not maintained by Cygwin, and it can be changed without the user even being aware of it. Cygwin apps might try to use fonts in that folder without knowing that the font cache is out of date. Fonts installed by texlive are different because the texlive postinstall scripts call fc-cache whenever fonts are installed. So the font caches are kept up to date. All that's needed for this to work is for /etc/fonts/fonts.conf to list the appropriate directories, as they used to. Maybe I could suggest the texlive-collection-* packages add the appropriate folder in a file/symlinked file in /etc/fonts/conf.d That's certainly another option, and I'll do it that way if Yaakov (the fontconfig maintainer) prefers it. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Setup 2.774 texlive postinstall takes 10+ hours
On 11/11/2014 12:08 PM, Achim Gratz wrote: Corinna Vinschen writes: On Nov 11 10:02, Ken Brown wrote: Of course, this still doesn't solve the problem of making sure that the _autorebase postinstall script runs whenever the user installs a package containing DLLs. I wonder if we should reconsider Achim's proposal. If I understand correctly, it is something like this (oversimplified): 1. Change autorebase.bat to do an incremental rebase instead of trying to do a full rebase. 2. Arrange for autorebase.bat to never be marked as done. Achim, please correct me if my oversimplification distorts your suggestion too much. Achim, can you give a management summary how your proposal works? As Ken already correctly summarized, the autorebase postinstall script will never be marked as done by setup.exe, so it will be run on each install or update. The incremental part ensures that this step doesn't take too much time if there's nothing to do. Currently this is based on the name of that script, but it could be done differently. The other part is that all perpetual postinstall scripts are run before any normal postinstall scripts, so these can assume to run in a correctly rebased environment. This seems like a very simple solution to the problem. I like it a lot. A slightly modified variant of the same mechanism could be used for those infodir, icon cache and fontconfig updates, which should probably be run after the normal postinstall scripts. I think I've sent Ken a sketch doing this from within a postinstall script for the texlive packages, but providing some support from setup.ini and setup.exe for stratified postinstalls (pre-post and post-post :-) would make this much more robust. I haven't yet coded up anything in that direction, though. If you're wondering what happens when you've just installed a fresh Cygwin: the perpetual rebase postinstall scripts detects the situation and bails out, while the normal postinstall script does the initial rebase (and is marked done). Which means we have to fix the dependency problem anyway. Incremental autorebase packages and patched setup.exe available on request. I'd like to see them. Thanks. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Notable performance improvement in 64-bit build
Hello everyone, I'm just curious, has there been any special focus on performance improvements in the 64-bit version compared to 32-bit? I'm asking because I recently upgraded from 32-bit to 64-bit Cygwin, and I noticed that my bash prompt would show up noticeably quicker when I opened a new Cygwin shell (I have a rather complicated ~/.profile script, so the delay is actually visible to the eye). At first I thought it was just some sort of placebo effect and I was imagining it, but the effect seemed so persistent that I just had to perform some measurements. What I found was that under 32-bit Cygwin my ~/.profile script is executed in 507ms (average of 30 runs), but under 64-bit Cygwin the exact same script gets executed in 376ms (again, 30-run average). Both measurements were done on the same machine with 32-bit and 64-bit Cygwin installed side by side (both freshly updated to their latest respective versions). That's a whopping 33% performance improvement! So I was just curious if anyone had any speculations on what exactly might have caused this performance increase. :) In any case, kudos to the Cygwin developers, great job on the 64-bit build! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: autogen-5.18.4-1
The following packages have been updated in the Cygwin distribution: * autogen-5.18.4-1 * libopts25-5.18.4-1 * libopts-devel-5.18.4-1 AutoGen is a tool designed to simplify the creation and maintenance of programs that contain large amounts of repetitious text. It is especially valuable in programs that have several blocks of text that must be kept synchronized. AutoOpts is an option processing library based on AutoGen. This is an update to the latest upstream release. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: libssh2-1.4.3-1
The following packages have been updated in the Cygwin distribution: * libssh2_1-1.4.3-1 * libssh2-devel-1.4.3-1 libssh2 is a library implementing the SSH2 protocol. This release is an update to the latest upstream release. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin setup program questions
On 11/12/2014 3:28 AM, t s wrote: I have some elementary questions regarding the cygwin setup program. I ran the latest version 2.852 (64 bit). wrong mailing list. Use main one for these questions the options are install / re-install / un-install / default my understanding is as follows; choosing install creates a new installation of the selected cygwin components choosing re-install uninstalls the selected cygwin components, then creates a new installation choosing un-install uninstalls the selected cygwin components choosing default updates the selected cygwin components so if I wish to update my local installation to the latest release, I would choose default, as per the following screen capture; http://www.cpm86.com/default.jpg What is the function of the keep / cur / exp radio buttons? Please confirm my understanding of these four options. Thanks. https://cygwin.com/cygwin-ug-net/setup-net.html#setup-packages Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated: autogen-5.18.4-1
The following packages have been updated in the Cygwin distribution: * autogen-5.18.4-1 * libopts25-5.18.4-1 * libopts-devel-5.18.4-1 AutoGen is a tool designed to simplify the creation and maintenance of programs that contain large amounts of repetitious text. It is especially valuable in programs that have several blocks of text that must be kept synchronized. AutoOpts is an option processing library based on AutoGen. This is an update to the latest upstream release. -- Yaakov
Updated: libssh2-1.4.3-1
The following packages have been updated in the Cygwin distribution: * libssh2_1-1.4.3-1 * libssh2-devel-1.4.3-1 libssh2 is a library implementing the SSH2 protocol. This release is an update to the latest upstream release. -- Yaakov
