Re: cygpath compatiblity break (v2.1 -> v2.7)
Dear All, I tried to understand how the mailing list work, but I cannot find any thread number or message number from the following. Moreover we haven't discussed my issue with `cygpath` which is a serious compatibility break in my toolchain. Changing the executable doesn't change anything because I think `cygpath` is somehow linked to a Cygwin dll which have the bug. So two questions in this thread: 1. How can I participate to the thread and use this mailing list properly? 2. What workaround can I use with my Cypath issue? Regards, Yves From: Brian Inglis To: cygwin at cygwin dot com Date: Wed, 26 Apr 2017 10:37:34 -0600 Subject: Re: cygpath compatiblity break (v2.1 -> v2.7) Authentication-results: sourceware.org; auth=none References: <0d835e9b9cd07f40a48423f80d3b5a704bc07...@usa7109mb022.na.xerox.net> <7ddd6386-4463-ec7e-14b0-dc1b719c9...@systematicsw.ab.ca> <36feeb13-b77d-1c2a-d31a-e1e6241e4...@systematicsw.ab.ca> <3094b7cc-7745-1160-e77e-0ef8b90bd...@gmail.com> Reply-to: Brian dot Inglis at SystematicSw dot ab dot ca On 2017-04-26 09:20, cyg Simple wrote: > On 4/25/2017 9:51 PM, Brian Inglis wrote: >> On 2017-04-25 19:12, Brian Inglis wrote: >>> On 2017-04-25 03:16, Andrew Schulman wrote: > From: Yves Chevallier >> How can I use this mailing list to answer a mail that I >> only find from this link >> https://www.cygwin.com/ml/cygwin/2017-04/msg00156.html? > Send a plain-text e-mail to cygwin-get.207...@cygwin.com. No > need to add a subject or body. It will send you the message, > and you can reply to that. Whoa. This should be documented somewhere. Looks like the 207653 comes from the Return-Path header when you view the raw message content. >>> It's documented in all subscription confirmation and acknowledgement >>> emails from the mailing list manager, unless you subscribed before >>> ezmlm was used, and you can get it by sending a blank plain text >>> email to -h...@cygwin.com e.g. mailto:cygwin-h...@cygwin.com. >> [last line scrambled by email address obscurer] >> email to -help at cygwin dot com e.g. cygwin-help at cygwin dot com > I was going to state the same yesterday but I gave it a try first. > The resulting mail doesn't explain the use of cygwin-get.MSGID that I > saw. It mostly refers to the FAQ on cygwin.com. Other lists' help is more informative - single message retrieval based on the ml msg# is implied, but the source of that number is not obvious: "To get messages 123 through 145 (a maximum of 100 per request), mail: To get an index with subject and author for messages 123-456 , mail: They are always returned as sets of 100, max 2000 per request, so you'll actually get 100-499. To receive all messages with the same subject as message 12345, send an empty message to: " should be added to the cygwin ml help, as should the source of the msg# as being the number in the raw message Return-path: header, and -help should be a command, and added to the ml help. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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 -- 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: xz-5.2.2: No threaded compression
On 10/05/17 01:15, Yaakov Selkowitz wrote: On 2017-05-09 18:02, David Stacey wrote: The man page for xz suggests that threaded compression ought to be available. However, when I run 'xz --threads=0 ' only one CPU core is used. Is there a way that I can run parallel xz compression in Cygwin? WFM. Note from the manpage: -T threads, --threads=threads Specify the number of worker threads to use. Setting threads to a special value 0 makes xz use as many threads as there are CPU cores on the system. The actual number of threads can be less than threads if the input file is not big enough for threading with the given settings or if using more threads would exceed the memory usage limit. That's helpful, thank you. The files I'm trying to compress are several GB, so I suppose I must be hitting the memory limit - which is surprising, given that I'm on a 64-bit system with a fair amount of RAM. I'll take a look at the source code and see if I can figure out what criteria it uses to enable or disable threaded compression. Thanks again, Dave. -- 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: [ANNOUNCEMENT] New: cygextreg-1.2.0-1
On 10.5.2017 0.48, Andrey Repin wrote: > Greetings, Joni Eskelinen! > >> On 5.5.2017 14.17, Andrey Repin wrote: >>> Greetings, Joni Eskelinen! >>> The following package has been added to the Cygwin distribution: >>> * cygextreg-1.2.0-1 >>> >>> Scripts are executed with bash >>> >>> This must not be the case, unless explicitly requested. Enough that >>> all Windows associations are executed with cmd if you try to >>> CreateProcess blindly. Don't copy this mistake. >>> >> Bash is used as an intermediary shell that executes the script. >> Generally a shebang line denotes the actual interpreter. > >> Bash was chosen because it's bundled with a default Cygwin installation. > > /usr/bin/env is also in the default install. > And I'm using it to run scripts now. > See attached TCC wrapper. > Thanks for the pointers! I'll have a look if there's any added benefit. >>> If you want to make it useful, write a thin wrapper over exec() that >>> finds out and runs proper interpreter, and support it with options to >>> make interpreters happy. F.e. convert $0 to Cygwin path, if >>> interpreter don't understand native paths (i.e. dash cringe over >>> non-latin1 native paths and I yet to find out why). >>> >> All native paths are converted to Cygwin equivalents before invoking >> bash, > > That's not the right thing to do. You can't know if a "path" you convert is an > actual local filesystem path (except for $0, but even then, it is not always > necessary). > Arguments are tested whether they're local paths and only then converted. >> ie. $0 as in the path of the file that was clicked from Windows, >> and consecutive arguments if some files were dragged and dropped to >> registered file icon. >> That is, the script shall always receive only Posix style paths, by design. > > You have a strangely limited perception on the usability of your tool. > How about console invocation? > Sorry but i fail to see your point. The whole rationale of this tool is to avoid console, to provide simple point and click interface for users to invoke shell scripts. in an interactive login shell. >>> >>> This should be optional. Login shell may cause $(pwd) to change, not >>> to mention, it alters environment. >>> If the executed script exits with a non-zero code, MinTTY window >>> >>> This should be optional. >>> shall be kept open >>> >>> This should be optional. >>> >> Nice suggestions. I've thought to implement per extension options >> especially for keeping the window open after completion. > >> Script is actually invoked roughly as follows: >> /bin/bash -il -c 'cd && ./' > > So, you're intentionally changing execution environment? > Yes exactly. This is by design. Typical use case is that a script performs something in its containing diretory, ie. compile or generate something relative to its location. >> with proper escaping applied. So even though user's personal init script >> changes the working directory, the script will be invoked in its >> containing directory. > > Which is not necessarily the place where user had it invoked. > Not necessarily but generally yes, script's directory is always the place it has been invoked. This is the case when you double click it from Explorer or drag & drop something to it. If one has more specific needs, then there's the usual tools to accomplish that. >> I think it's a reasonable default to have bash run this way, since >> there's a fair chance that scripts require environmental variables set >> in .bashrc or like (eg. $PATH to ruby gems). > > I'm not in the favor of chances when I'm doing my work. > There's no way to make everyone happy, isn't there? :) Luckily this tool is open for forking and i welcome you to open suggestions at https://github.com/sop/cygextreg/issues. - Joni -- 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: Installing sshd with option --type manual
On 5/4/2017 3:31 PM, Fran Litterio wrote: You can try opening the Services Control Panel app (run "start services.msc" in a Command Prompt) and changing the startup type of service "Cygwin sshd" to "Automatic (Delayed Start)". Yes! I was looking in the alphabetized list of services for sshd, not for CYGWIN sshd. Thanks -- 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: fontspec
On 5/9/2017 7:40 PM, Leon Meier wrote: @Ken: Thank you for updating texlive! fontspec v2.6a works like a charm; the nasty bug is out. Glad to hear it. Thanks for the feedback. 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: xz-5.2.2: No threaded compression
On 2017-05-09 18:02, David Stacey wrote: The man page for xz suggests that threaded compression ought to be available. However, when I run 'xz --threads=0 ' only one CPU core is used. Is there a way that I can run parallel xz compression in Cygwin? WFM. Note from the manpage: -T threads, --threads=threads Specify the number of worker threads to use. Setting threads to a special value 0 makes xz use as many threads as there are CPU cores on the system. The actual number of threads can be less than threads if the input file is not big enough for threading with the given settings or if using more threads would exceed the memory usage limit. -- 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
fontspec
@Ken: Thank you for updating texlive! fontspec v2.6a works like a charm; the nasty bug is 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
xz-5.2.2: No threaded compression
The man page for xz suggests that threaded compression ought to be available. However, when I run 'xz --threads=0 ' only one CPU core is used. Is there a way that I can run parallel xz compression in Cygwin? Dave. -- 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: [ANNOUNCEMENT] New: cygextreg-1.2.0-1
Greetings, Joni Eskelinen! > On 5.5.2017 14.17, Andrey Repin wrote: >> Greetings, Joni Eskelinen! >> >>> The following package has been added to the Cygwin distribution: >> >>> * cygextreg-1.2.0-1 >> >> >>> Scripts are executed with bash >> >> This must not be the case, unless explicitly requested. Enough that >> all Windows associations are executed with cmd if you try to >> CreateProcess blindly. Don't copy this mistake. >> > Bash is used as an intermediary shell that executes the script. > Generally a shebang line denotes the actual interpreter. > Bash was chosen because it's bundled with a default Cygwin installation. /usr/bin/env is also in the default install. And I'm using it to run scripts now. See attached TCC wrapper. >> If you want to make it useful, write a thin wrapper over exec() that >> finds out and runs proper interpreter, and support it with options to >> make interpreters happy. F.e. convert $0 to Cygwin path, if >> interpreter don't understand native paths (i.e. dash cringe over >> non-latin1 native paths and I yet to find out why). >> > All native paths are converted to Cygwin equivalents before invoking > bash, That's not the right thing to do. You can't know if a "path" you convert is an actual local filesystem path (except for $0, but even then, it is not always necessary). > ie. $0 as in the path of the file that was clicked from Windows, > and consecutive arguments if some files were dragged and dropped to > registered file icon. > That is, the script shall always receive only Posix style paths, by design. You have a strangely limited perception on the usability of your tool. How about console invocation? >>> in an interactive login shell. >> >> This should be optional. Login shell may cause $(pwd) to change, not >> to mention, it alters environment. >> >>> If the executed script exits with a non-zero code, MinTTY window >> >> This should be optional. >> >>> shall be kept open >> >> This should be optional. >> > Nice suggestions. I've thought to implement per extension options > especially for keeping the window open after completion. > Script is actually invoked roughly as follows: > /bin/bash -il -c 'cd && ./' So, you're intentionally changing execution environment? > with proper escaping applied. So even though user's personal init script > changes the working directory, the script will be invoked in its > containing directory. Which is not necessarily the place where user had it invoked. > I think it's a reasonable default to have bash run this way, since > there's a fair chance that scripts require environmental variables set > in .bashrc or like (eg. $PATH to ruby gems). I'm not in the favor of chances when I'm doing my work. -- With best regards, Andrey Repin Tuesday, May 9, 2017 17:15:35 Sorry for my terrible english... cygwrap.btm Description: Binary data -- 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] bind 9.11.0-3.P5
The following packages have been uploaded to the Cygwin distribution: * bind-9.11.0-3.P5 * bind-utils-9.11.0-3.P5 * bind-doc-9.11.0-3.P5 * libbind9_160-9.11.0-3.P5 * libdns166-9.11.0-3.P5 * libirs160-9.11.0-3.P5 * libisc160-9.11.0-3.P5 * libisccc160-9.11.0-3.P5 * libisccfg160-9.11.0-3.P5 * liblwres160-9.11.0-3.P5 * libbind9-devel-9.11.0-3.P5 * python-isc-9.11.0-3.P5 BIND is an implementation of the Domain Name System (DNS) protocols. The DNS protocols are part of the core Internet standards. They specify the process by which one computer can find another computer on the basis of its name. The BIND software distribution contains all of the software needed both to ask name service questions and to answer such questions. This release includes fixes for CVE-2017-3136, CVE-2017-3137, and CVE-2017-3138: ftp://ftp.isc.org/isc/bind9/9.11.0-P5/RELEASE-NOTES-bind-9.11.0-P5.html -- 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] dialog 1.3-3.20170131
The following packages have been uploaded to the Cygwin distribution: * dialog-1.3-3.20170131 * libdialog14-1.3-3.20170131 * libdialog-devel-1.3-3.20170131 A script-interpreter which provides a set of curses widgets. Widgets are objects whose appearance and behavior can be customized. This is an update to the latest upstream release, which includes an ABI version bump to the otherwise-unused libdialog. -- 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] asciinema 1.4.0-1
The following packages have been uploaded to the Cygwin distribution: * asciinema-1.4.0-1 asciinema is a free and open source solution for recording terminal sessions and sharing them on the web. It aims to be a go to place for every command-line user who wants to share their skills with others. This is an update to the latest upstream release: https://github.com/asciinema/asciinema/blob/master/CHANGELOG.md#140-2017-04-11 -- 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] asciidoc 8.6.9-1
The following packages have been uploaded to the Cygwin distribution: * asciidoc-8.6.9-1 AsciiDoc is a text document format for writing short documents, articles, books and UNIX man pages. AsciiDoc files can be translated to HTML and DocBook markups using the asciidoc(1) command. This is an update to the latest upstream release: http://www.methods.co.nz/asciidoc/CHANGELOG.html -- 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] cgit 1.1-1
The following packages have been uploaded to the Cygwin distribution: * cgit-1.1-1 This is an attempt to create a fast web interface for the git scm, using a builtin cache to decrease server io-pressure. 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] dblatex 0.3.10-1
The following packages have been uploaded to the Cygwin distribution: * dblatex-0.3.10-1 dblatex is a program that transforms your SGML/XML DocBook documents to DVI, PostScript or PDF by translating them into pure LaTeX as a first process. MathML 2.0 markups are supported, too. This is an update to the latest upstream release, which includes fixes for the latest TeX Live macros. -- 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] byacc 20170430-1
The following packages have been uploaded to the Cygwin distribution: * byacc-20170430-1 Berkeley Yacc is an LALR(1) parser generator. Berkeley Yacc has been made as compatible as possible with AT&T Yacc. Berkeley Yacc can accept any input specification that conforms to the AT&T Yacc documentation. 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
Re: setup release candidate - please test
Greetings, Jon Turney! > On 08/05/2017 17:27, Brian Inglis wrote: >> >> wget download no longer sets x bits and won't run from Explorer, >> cygstart, or bash: > No longer? I don't think wget ever did this. >> $ cygstart ./setup-2.878.x86_64 >> Unable to start 'setup-2.878.x86_64.exe': The operating system denied access >> to the specified file. >> $ cygstart ./setup-2.878.x86_64.exe >> Unable to start 'setup-2.878.x86_64.exe': The operating system denied access >> to the specified file. >> $ ./setup-2.878.x86_64 >> -bash: ./setup-2.878.x86_64: Permission denied >> $ ./setup-2.878.x86_64.exe >> -bash: ./setup-2.878.x86_64.exe: Permission denied >> >> - requires chmod +x to run. It never did by itself, but if you download to a location with windows-controlled ACL, the executable bit will be set by OS. -- With best regards, Andrey Repin Tuesday, May 9, 2017 20:52:27 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: [ANNOUNCEMENT] New: cygextreg-1.2.0-1
On 2017-05-09 00:30, Joni Eskelinen wrote: > On 4.5.2017 18.48, Brian Inglis wrote: >> On 2017-05-04 01:29, Joni Eskelinen wrote: >>> The following package has been added to the Cygwin distribution: >>> * cygextreg-1.2.0-1 >>> CygExtReg is a utility program allowing to register an extension >>> (eg. .sh) to be executed in Cygwin by double-clicking a file from >>> Windows File Explorer or by dragging and dropping files to an icon of >>> a registered extension. >>> https://github.com/sop/cygextreg >> Are there any good sources of freely redistributable icon sets from >> windows systems or launchers for Unix utilities e.g. gnome, mate, >> pcmanfm, etc.? > There's a Tango Desktop Project providing a lot of icons with CC > license. See https://commons.wikimedia.org/wiki/Tango_icons. > Also i've found Iconfinder to be quite useful. It has both commercial > and open source licensed icons available. See > https://www.iconfinder.com/search/. Thanks for the links - I'll do some browsing. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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 release candidate - please test
On 2017-05-09 03:57, Jon Turney wrote: > On 08/05/2017 17:27, Brian Inglis wrote: >> wget download no longer sets x bits and won't run from Explorer, >> cygstart, or bash: > No longer? I don't think wget ever did this. >> $ cygstart ./setup-2.878.x86_64 >> Unable to start 'setup-2.878.x86_64.exe': The operating system denied access >> to the specified file. >> $ cygstart ./setup-2.878.x86_64.exe >> Unable to start 'setup-2.878.x86_64.exe': The operating system denied access >> to the specified file. >> $ ./setup-2.878.x86_64 >> -bash: ./setup-2.878.x86_64: Permission denied >> $ ./setup-2.878.x86_64.exe >> -bash: ./setup-2.878.x86_64.exe: Permission denied >> - requires chmod +x to run. Never had to chmod -x setup in my download, check, launch script until now - it used to just check it was -x and complain if not, which it did this time, pre-fix! Did not require that on my last (wget -N) download of the current setup release, but now does. Consistent across directories, Cygwin, and Windows DACLs. Could be Windows, Cygwin, or wget change - not worried about cause. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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: setting TZ is harmful
On 2017-05-09 08:09, Gluszczak, Glenn wrote: > Ran into issues with TZ in the past too. ActiveState Perl is picky. > I use the PST8PDT format for TZ, but could be other Window programs > that won't accept that. Default rules used for that format in tzcode are those for pre-2007 North America, until changes coming in the next tzcode release are incorporated into downstream libraries, when rules will default to post-2007 North America. Many libraries, including Cygwin, use their own implementations of some tzcode functions, so may use different rules, or not pick up code updates until years later. Better to set up an /etc/localtime symlink to zoneinfo/.../... for Cygwin and let Windows programs do their own thing, which may be neither currently nor historically correct. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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: Please enable cid-x.map in dvipdfmx.cfg when installing texlive-langjapanese
On 5/9/2017 7:22 AM, Lemures Lemniscati wrote: My situation has been resolved on x86_64 version by: (1) removing /var/lib/texmf (2) reinstalling texlive-* packages It seemed the cause that /var/lib/texmf/fonts/map/dvipdfmx/updmap/kanjix.map was not updated properly. On x86 version, I can't resolve it yet, and still keep trying... Check the logs in /var/log to see if some of the postinstall scripts had fork failures. Unfortunately, this is fairly common on x86, and a full rebase (perhaps followed by a reboot) might be necessary. See https://cygwin.com/ml/cygwin/2017-05/msg00087.html for example. 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: pure-ftpd fatal error in forked process - fork: can't reserve memory for parent Cygwin x86 Operating Systems
On 16/11/2016 07:31, OwN-3m-All wrote: pure-ftpd is run using the following command: /usr/sbin/pure-ftpd.exe -S 0.0.0.0,21 -lpuredb:/etc/pureftpd.pdb -g /var/run/pure-ftpd.pid & I can't get any FTP account to work. Attached is the cygcheck.out. Thanks for taking a look. can you check if latest version is working for you ? Sorry for taking too long to solve the issue 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: setting TZ is harmful
Ran into issues with TZ in the past too. ActiveState Perl is picky.
I use the PST8PDT format for TZ, but could be other Window programs that
won't accept that.
$ TZ="" date
Tue, May 9, 2017 2:02:50 PM
$ TZ="America/Los_Angeles" date
Tue, May 9, 2017 7:01:39 AM
$ TZ="PST8PEDT" date
Tue, May 9, 2017 7:01:49 AM
Cygwin Perl
=
$ TZ="" perl -e "print scalar localtime(time);"
Tue May 9 13:59:57 2017
$ TZ="America/Los_Angeles" perl -e "print scalar localtime(time);"
Tue May 9 07:00:28 2017
$ TZ="PST8PDT" perl -e "print scalar localtime(time);"
Tue May 9 07:00:45 2017
ActiveState Perl
$ TZ="" ./perl -e "print scalar localtime(time);"
Tue May 9 07:06:06 2017
$ TZ="America/Los_Angeles" ./perl -e "print scalar localtime(time);"
Tue May 9 15:06:29 2017
$ TZ="PST8PDT" ./perl -e "print scalar localtime(time);"
Tue May 9 07:06:47 2017
Glenn
Hi,
Currently, all commands in a Cygwin command window are run with the TZ
environment variable set.
It is set by /etc/profile.d/tzset.sh (or its csh equivalent,
/etc/profile.d/tzset.csh).
Setting TZ is harmful in two ways:
1) When the user changes the time zone (through the Windows Control Panel) -
for example when traveling - the programs run in the Cygwin command
window will display a stale notion of local time. Only after the user
closes and re-opens a new Cygwin command window, will the programs
display local time according to the new time zone.
2) It causes native Windows programs (built through mingw, MSVC) to assume
a time zone that is different from the intended one and different from
the one that the user has set in the Windows Control Panel (see APPENDIX 1
below). This is because in most geographies, the values of TZ (produced
by winsup/utils/tzset.c and winsup/utils/tzmap.h) contains a slash, and
the tzset() function in the Microsoft CRT does not understand this syntax
- it understands only a different syntax
https://msdn.microsoft.com/en-us/library/90s5c885.aspx .
When TZ is not set, both Cygwin and native Windows programs take their time
zone information from the Windows Control Panel settings. See APPENDIX 2 below
and https://lists.gnu.org/archive/html/bug-gnulib/2017-05/msg00035.html .
What are the benefits of setting the TZ environment variable? I don't see any!
===> Please remove /etc/profile.d/tzset.{sh,csh} ! <===
Side note: An empty TZ value is equivalent to an unset TZ variable for mingw
and MSVC compiled programs, but not for Cygwin programs (which interpret it as
GMT). See APPENDIX 2 below.
Bruno
=== APPENDIX 1: Effects of Cygwin-set TZ on programs =
$ ./showtime-cygwin.exe
now = 17286 17 157
as GMT: 2017-04-30 17:02:37 dst=0
as GMT: Sun Apr 30 17:02:37 2017
as localtime: 2017-04-30 19:02:37 dst=1
as localtime: Sun Apr 30 19:02:37 2017 tzname[0] = CET, tzname[1] = CEST
$ ./showtime-mingw.exe
now = 17286 17 175
as GMT: 2017-04-30 17:02:55 dst=0
as GMT: Sun Apr 30 17:02:55 2017
as localtime: 2017-04-30 18:02:55 dst=1
as localtime: Sun Apr 30 18:02:55 2017 tzname[0] = Eur, tzname[1] = ope
$ ./showtime-msvc.exe
now = 17286 17 234
as GMT: 2017-04-30 17:03:54 dst=0
as GMT: Sun Apr 30 17:03:54 2017
as localtime: 2017-04-30 18:03:54 dst=1
as localtime: Sun Apr 30 18:03:54 2017 tzname[0] = Eur, tzname[1] = ope
=== APPENDIX 2: Effects of unset TZ or empty TZ on programs ===
Cygwin: makes a difference
$ (unset TZ; ./showtime-cygwin.exe )
now = 17292 20 3383
as GMT: 2017-05-06 20:56:23 dst=0
as GMT: Sat May 6 20:56:23 2017
as localtime: 2017-05-06 22:56:23 dst=1
as localtime: Sat May 6 22:56:23 2017 tzname[0] = WEST, tzname[1] = WEST
$ TZ= ./showtime-cygwin.exe
now = 17292 20 3420
as GMT: 2017-05-06 20:57:00 dst=0
as GMT: Sat May 6 20:57:00 2017
as localtime: 2017-05-06 20:57:00 dst=0
as localtime: Sat May 6 20:57:00 2017 tzname[0] = GMT, tzname[1] =
mingw: no difference
$ (unset TZ; ./showtime-mingw.exe )
now = 17292 20 3395
as GMT: 2017-05-06 20:56:35 dst=0
as GMT: Sat May 06 20:56:35 2017
as localtime: 2017-05-06 22:56:35 dst=1
as localtime: Sat May 06 22:56:35 2017 tzname[0] = W. Europe Standard Time,
tzname[1] = W. Europe Summer Time
$ TZ= ./showtime-mingw.exe
now = 17292 20 3426
as GMT: 2017-05-06 20:57:06 dst=0
as GMT: Sat May 06 20:57:06 2017
as localtime: 2017-05-06 22:57:06 dst=1
as localtime: Sat May 06 22:57:06 2017 tzname[0] = W. Europe Standard Time,
tzname[1] = W. Europe Summer Time
msvc: no difference
$ (unset TZ; ./showtime-msvc.exe )
now = 17292 20 3401
as GMT: 2017-05-06 20:56:41 dst=0
as GMT: Sat May 6 20:56:41 2017
as localtime: 2017-05-06 22:56:41 dst=1
as localtime: Sat May 6 22:56:41 2017 tzname[0] = W. Europe Standard Time,
tzname[1] = W. Europe Summer Time
$ TZ= ./showtime-msvc.exe
now = 17292 20 3431
as GMT: 2017-05-06 20:57:11 dst=0
as GMT: Sat
setting TZ is harmful
Hi,
Currently, all commands in a Cygwin command window are run with the TZ
environment variable set.
It is set by /etc/profile.d/tzset.sh (or its csh equivalent,
/etc/profile.d/tzset.csh).
Setting TZ is harmful in two ways:
1) When the user changes the time zone (through the Windows Control Panel) -
for example when traveling - the programs run in the Cygwin command
window will display a stale notion of local time. Only after the user
closes and re-opens a new Cygwin command window, will the programs
display local time according to the new time zone.
2) It causes native Windows programs (built through mingw, MSVC) to assume
a time zone that is different from the intended one and different from
the one that the user has set in the Windows Control Panel (see APPENDIX 1
below). This is because in most geographies, the values of TZ (produced
by winsup/utils/tzset.c and winsup/utils/tzmap.h) contains a slash, and
the tzset() function in the Microsoft CRT does not understand this syntax
- it understands only a different syntax
https://msdn.microsoft.com/en-us/library/90s5c885.aspx .
When TZ is not set, both Cygwin and native Windows programs take their time
zone information from the Windows Control Panel settings. See APPENDIX 2
below and https://lists.gnu.org/archive/html/bug-gnulib/2017-05/msg00035.html .
What are the benefits of setting the TZ environment variable? I don't
see any!
===> Please remove /etc/profile.d/tzset.{sh,csh} ! <===
Side note: An empty TZ value is equivalent to an unset TZ variable for mingw
and MSVC compiled programs, but not for Cygwin programs (which interpret it as
GMT). See APPENDIX 2 below.
Bruno
=== APPENDIX 1: Effects of Cygwin-set TZ on programs =
$ ./showtime-cygwin.exe
now = 17286 17 157
as GMT: 2017-04-30 17:02:37 dst=0
as GMT: Sun Apr 30 17:02:37 2017
as localtime: 2017-04-30 19:02:37 dst=1
as localtime: Sun Apr 30 19:02:37 2017
tzname[0] = CET, tzname[1] = CEST
$ ./showtime-mingw.exe
now = 17286 17 175
as GMT: 2017-04-30 17:02:55 dst=0
as GMT: Sun Apr 30 17:02:55 2017
as localtime: 2017-04-30 18:02:55 dst=1
as localtime: Sun Apr 30 18:02:55 2017
tzname[0] = Eur, tzname[1] = ope
$ ./showtime-msvc.exe
now = 17286 17 234
as GMT: 2017-04-30 17:03:54 dst=0
as GMT: Sun Apr 30 17:03:54 2017
as localtime: 2017-04-30 18:03:54 dst=1
as localtime: Sun Apr 30 18:03:54 2017
tzname[0] = Eur, tzname[1] = ope
=== APPENDIX 2: Effects of unset TZ or empty TZ on programs ===
Cygwin: makes a difference
$ (unset TZ; ./showtime-cygwin.exe )
now = 17292 20 3383
as GMT: 2017-05-06 20:56:23 dst=0
as GMT: Sat May 6 20:56:23 2017
as localtime: 2017-05-06 22:56:23 dst=1
as localtime: Sat May 6 22:56:23 2017
tzname[0] = WEST, tzname[1] = WEST
$ TZ= ./showtime-cygwin.exe
now = 17292 20 3420
as GMT: 2017-05-06 20:57:00 dst=0
as GMT: Sat May 6 20:57:00 2017
as localtime: 2017-05-06 20:57:00 dst=0
as localtime: Sat May 6 20:57:00 2017
tzname[0] = GMT, tzname[1] =
mingw: no difference
$ (unset TZ; ./showtime-mingw.exe )
now = 17292 20 3395
as GMT: 2017-05-06 20:56:35 dst=0
as GMT: Sat May 06 20:56:35 2017
as localtime: 2017-05-06 22:56:35 dst=1
as localtime: Sat May 06 22:56:35 2017
tzname[0] = W. Europe Standard Time, tzname[1] = W. Europe Summer Time
$ TZ= ./showtime-mingw.exe
now = 17292 20 3426
as GMT: 2017-05-06 20:57:06 dst=0
as GMT: Sat May 06 20:57:06 2017
as localtime: 2017-05-06 22:57:06 dst=1
as localtime: Sat May 06 22:57:06 2017
tzname[0] = W. Europe Standard Time, tzname[1] = W. Europe Summer Time
msvc: no difference
$ (unset TZ; ./showtime-msvc.exe )
now = 17292 20 3401
as GMT: 2017-05-06 20:56:41 dst=0
as GMT: Sat May 6 20:56:41 2017
as localtime: 2017-05-06 22:56:41 dst=1
as localtime: Sat May 6 22:56:41 2017
tzname[0] = W. Europe Standard Time, tzname[1] = W. Europe Summer Time
$ TZ= ./showtime-msvc.exe
now = 17292 20 3431
as GMT: 2017-05-06 20:57:11 dst=0
as GMT: Sat May 6 20:57:11 2017
as localtime: 2017-05-06 22:57:11 dst=1
as localtime: Sat May 6 22:57:11 2017
tzname[0] = W. Europe Standard Time, tzname[1] = W. Europe Summer Time
--
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 release candidate - please test
On 5/9/2017 6:03 AM, Jon Turney wrote: On 08/05/2017 14:33, Eliot Moss wrote: On 5/8/2017 7:06 AM, Jon Turney wrote: A setup release candidate is available at: https://cygwin.com/setup/setup-2.878.x86.exe https://cygwin.com/setup/setup-2.878.x86_64.exe Both worked flawlessly for me. I run Windows 10, Creator Update (most recent release AFAIK). One difference from before is that I get a Windows Defender SmartScreen pop-up. I have to click the "More info" option and then a "Run anyway" button appears, allowing me to run the setup program. AFAICT, this happens only the *first* time I run the setup program. Thereafter, WIndows Defender does not complain. Thanks for testing. Is Windows 10 1703 more picky about letting you run unsigned executables? I think so - I don't recall needing to do this with setup ever before. As discussed previously, the problems with getting setup signed are logistical rather than technical. It's not a huge deal, particularly since it happens only the first time I run setup. I suppose the concern would be users who don't figure out the right clicks or who are suspicious of doing that, and automated installs. Regards - EM -- 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: Please enable cid-x.map in dvipdfmx.cfg when installing texlive-langjapanese
Hi!
> echo '\documentclass{jsarticle}\begin{document}\char\euc"A4A2\end{document}'|
> platex -jobname test; dvipdfmx test
My situation has been resolved on x86_64 version by:
(1) removing /var/lib/texmf
(2) reinstalling texlive-* packages
It seemed the cause that
/var/lib/texmf/fonts/map/dvipdfmx/updmap/kanjix.map
was not updated properly.
On x86 version, I can't resolve it yet, and still keep trying...
Regards,
--
Lemures Lemniscati
==
Subject: Re: Please enable cid-x.map in dvipdfmx.cfg when installing
texlive-langjapanese
Date: Tue, 09 May 2017 06:55:20 +0900
From: Lemures Lemniscati
> Hi!
>
> > > echo
> > > '\documentclass{jsarticle}\begin{document}\char\euc"A4A2\end{document}'|
> > > platex -jobname test; dvipdfmx test
> >
> > Works fine for me:
>
> All right, I'll test again and report after reinstall.
>
> Thanks.
>
> --
> Lemures Lemniscati
>
>
> ==
> Subject: Re: Please enable cid-x.map in dvipdfmx.cfg when installing
> texlive-langjapanese
> Date: Mon, 8 May 2017 10:23:23 -0400
> From: Ken Brown
>
> > On 5/8/2017 9:54 AM, Lemures Lemniscati via cygwin wrote:
> > > Thank you for replying.
> > >
> > >> Now that I've looked at this more closely, I'm not sure your suggestion
> > >> is the right thing to do. I don't see anything like it in a native TeX
> > >> Live installation. Please send me a complete, detailed recipe for
> > >> reproducing your problem so that I can investigate further.
> > >
> > > I see and agree:
> > >
> > > The file usr/share/texmf-dist/dvipdfmx/dvipdfmx.cfg is the same as it
> > > was in the previous package, and we didn't need such modifications.
> > > So, maybe something wrong... or not...
> > >
> > >
> > > Anyway, how to reproduce the situation:
> > >
> > > echo
> > > '\documentclass{jsarticle}\begin{document}\char\euc"A4A2\end{document}'|
> > > platex -jobname test; dvipdfmx test
> >
> > Works fine for me:
> >
> > $ echo
> > '\documentclass{jsarticle}\begin{document}\char\euc"A4A2\end{document}'|
> > platex -jobname test; dvipdfmx test
> > This is e-pTeX, Version 3.14159265-p3.7-160201-2.6 (utf8.euc) (TeX Live
> > 2016/Cygwin) (preloaded format=platex)
> > restricted \write18 enabled.
> > **entering extended mode
> > pLaTeX2e <2016/11/29> (based on LaTeX2e <2017/01/01> patch level 3)
> > Babel <3.9r> and hyphenation patterns for 83 language(s) loaded.
> > (/usr/share/texmf-dist/tex/platex/jsclasses/jsarticle.cls
> > Document Class: jsarticle 2017/03/05 okumura, texjporg
> > (/usr/share/texmf-dist/tex/platex/jsclasses/jslogo.sty))
> > No file test.aux.
> > [1] (./test.aux)
> > Output written on test.dvi (1 page, 256 bytes).
> > Transcript written on test.log.
> > test -> test.pdf
> > [1]
> > 3532 bytes written
> >
> > And when I view test.pdf, it looks right.
> >
> > 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
--
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 release candidate - please test
On 08/05/2017 14:33, Eliot Moss wrote: On 5/8/2017 7:06 AM, Jon Turney wrote: A setup release candidate is available at: https://cygwin.com/setup/setup-2.878.x86.exe https://cygwin.com/setup/setup-2.878.x86_64.exe Both worked flawlessly for me. I run Windows 10, Creator Update (most recent release AFAIK). One difference from before is that I get a Windows Defender SmartScreen pop-up. I have to click the "More info" option and then a "Run anyway" button appears, allowing me to run the setup program. AFAICT, this happens only the *first* time I run the setup program. Thereafter, WIndows Defender does not complain. Thanks for testing. Is Windows 10 1703 more picky about letting you run unsigned executables? As discussed previously, the problems with getting setup signed are logistical rather than technical. -- 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 release candidate - please test
On 08/05/2017 12:38, Steven Penny via cygwin wrote: On Mon, 8 May 2017 12:06:31, Jon Turney wrote: Looks good, but I still hate the last screen. The "Create Icons" screen. Thanks for testing. We should be able to add the icon preference to this list. 'We' take patches. -- 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 release candidate - please test
On 08/05/2017 17:27, Brian Inglis wrote: wget download no longer sets x bits and won't run from Explorer, cygstart, or bash: No longer? I don't think wget ever did this. $ cygstart ./setup-2.878.x86_64 Unable to start 'setup-2.878.x86_64.exe': The operating system denied access to the specified file. $ cygstart ./setup-2.878.x86_64.exe Unable to start 'setup-2.878.x86_64.exe': The operating system denied access to the specified file. $ ./setup-2.878.x86_64 -bash: ./setup-2.878.x86_64: Permission denied $ ./setup-2.878.x86_64.exe -bash: ./setup-2.878.x86_64.exe: Permission denied - requires chmod +x to run. -- 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
