Re: Wrong expansion of ~/
On Mon, Aug 24, 2020 at 10:41 PM Brian Inglis wrote: > > On 2020-08-24 06:36, Morten Kjærulff via Cygwin wrote: > > On Mon, Aug 24, 2020 at 11:52 AM Thomas Wolff wrote: > >> Am 24.08.2020 um 10:05 schrieb Morten Kjærulff via Cygwin: > >>> I have a script that starts several tmux panes with my favorite commands. > >>> In some (*some* and only *sometimes*) of the panes I see: > >>> > >>> -bash: /home/xP/.git-completion.bash: No such file or directory > >>> -bash: /home/xP/.git-prompt.sh: No such file or directory > >>> > >>> My .bashrc has: > >>> > >>> $ grep git .bashrc > >>> . ~/.git-completion.bash > >>> . ~/.git-prompt.sh > >>> > >>> My userid is xf (and not xP). > >>> > >>> Is this known? > >> What if you trace `echo $HOME; echo ~` after the `.`? I have occasional > >> cases where $HOME and ~ start to be different in my shell, which is > >> quite weird and should not happen according to bash documentation. > > > > Ok, > > > > My userid is xx00mkf. > > > > > > If I add: > > > > . ~/.git-completion.bash > > if [ ! $? = 0 ] ; then > > echo "HOME=" $HOME > > echo "~=" ~ > > fi > > > > I see: > > > > -bash: /home/xx00m/.git-completion.bash: No such file or directory > > HOME= /home/xx00mkf > > ~= /home/xx00m > > > > > > If I add: > > > > . ~/.git-completion.bash > > if [ ! $? = 0 ] ; then > > echo "HOME=" $HOME > > echo "~=" ~ > > echo "~/.git-completion.bash=" ~/.git-completion.bash > > fi > > > > -bash: /home/xx00m/.git-completion.bash: No such file or directory > > HOME= /home/xx00mkf > > ~= /home/xx00mkf > > ~/.git-completion.bash= /home/xx00mkf/.git-completion.bash > > HOME dir depends on entries in: > > /etc/nsswitch.conf > > whether you have /etc/passwd and/or /etc/group files and their entries; > > your SAM and/or AD entry contents including e.g. > > $ net user $USER | grep '^Comment' > Comment > > You can check if any of these are in effect by running: > > $ getent passwd $USER > > If you think they are relevant, you might also want to try to trace and debug > your bash-completion setup scripts: > > $ set -vx > $ . /etc/profile.d/bash_completion.sh |& tee /tmp/completion.log | > less > > to see what they are doing that might affect other settings. Thanks, but ~ changes from xx01m to xx01mkf (which is correct) between a few commands in .bashrc: If I add: . ~/.git-completion.bash if [ ! $? = 0 ] ; then echo "HOME=" $HOME echo "~=" ~ echo "~/.git-completion.bash=" ~/.git-completion.bash fi I see (*sometimes*): -bash: /home/xx00m/.git-completion.bash: No such file or directory <
Re: Wrong expansion of ~/
On 2020-08-25 01:15, Morten Kjærulff via Cygwin wrote: > On Mon, Aug 24, 2020 at 10:41 PM Brian Inglis wrote: >> >> On 2020-08-24 06:36, Morten Kjærulff via Cygwin wrote: >>> On Mon, Aug 24, 2020 at 11:52 AM Thomas Wolff wrote: Am 24.08.2020 um 10:05 schrieb Morten Kjærulff via Cygwin: > I have a script that starts several tmux panes with my favorite commands. > In some (*some* and only *sometimes*) of the panes I see: > > -bash: /home/xP/.git-completion.bash: No such file or directory > -bash: /home/xP/.git-prompt.sh: No such file or directory > > My .bashrc has: > > $ grep git .bashrc > . ~/.git-completion.bash > . ~/.git-prompt.sh > > My userid is xf (and not xP). > > Is this known? What if you trace `echo $HOME; echo ~` after the `.`? I have occasional cases where $HOME and ~ start to be different in my shell, which is quite weird and should not happen according to bash documentation. >>> >>> Ok, >>> >>> My userid is xx00mkf. >>> >>> >>> If I add: >>> >>> . ~/.git-completion.bash >>> if [ ! $? = 0 ] ; then >>> echo "HOME=" $HOME >>> echo "~=" ~ >>> fi >>> >>> I see: >>> >>> -bash: /home/xx00m/.git-completion.bash: No such file or directory >>> HOME= /home/xx00mkf >>> ~= /home/xx00m >>> >>> >>> If I add: >>> >>> . ~/.git-completion.bash >>> if [ ! $? = 0 ] ; then >>> echo "HOME=" $HOME >>> echo "~=" ~ >>> echo "~/.git-completion.bash=" ~/.git-completion.bash >>> fi >>> >>> -bash: /home/xx00m/.git-completion.bash: No such file or directory >>> HOME= /home/xx00mkf >>> ~= /home/xx00mkf >>> ~/.git-completion.bash= /home/xx00mkf/.git-completion.bash >> >> HOME dir depends on entries in: >> >> /etc/nsswitch.conf >> >> whether you have /etc/passwd and/or /etc/group files and their entries; >> >> your SAM and/or AD entry contents including e.g. >> >> $ net user $USER | grep '^Comment' >> Comment >> >> You can check if any of these are in effect by running: >> >> $ getent passwd $USER >> >> If you think they are relevant, you might also want to try to trace and debug >> your bash-completion setup scripts: >> >> $ set -vx >> $ . /etc/profile.d/bash_completion.sh |& tee /tmp/completion.log | >> less >> >> to see what they are doing that might affect other settings. > > Thanks, but ~ changes from xx01m to xx01mkf (which is correct) between > a few commands in .bashrc: > > If I add: > > . ~/.git-completion.bash > if [ ! $? = 0 ] ; then > echo "HOME=" $HOME > echo "~=" ~ > echo "~/.git-completion.bash=" ~/.git-completion.bash > fi > > I see (*sometimes*): > > -bash: /home/xx00m/.git-completion.bash: No such file or directory << HOME= /home/xx00mkf > ~= /home/xx00mkf << ~/.git-completion.bash= /home/xx00mkf/.git-completion.bash <
Mandatory ASLR breaks Cygwin - Windows 10
I was experimenting with security settings this morning on windows, and after changing Mandatory ASLR (Windows Security -> App and Browser Control -> Exploit Protection) to default on, no Cygwin programs that rely on the Cygwin dll would start, stating that a resource was temporarily unavailable and could not fork. Rebasell, bash, you name it crashed and would not start. After some investigation, turning off that setting allows Cygwin to work. Now the next question: why does this not work? Is this intended behavior or a bug? Having that setting turned on seems like a good idea from a security standpoint, and who knows it may eventually become default. Regards, Alexandria C. cygcheck.out Description: Binary data -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mandatory ASLR breaks Cygwin - Windows 10
It’s intentional; too long to explain in detail on phone, but fork requires each dll to load in the child at the same address as in the parent, and ASLR interferes with achieving that. Sent from my iPhone > On Aug 25, 2020, at 10:17 AM, Alexandria Cortez wrote: > > I was experimenting with security settings this morning on windows, and > after changing Mandatory ASLR (Windows Security -> App and Browser Control > -> Exploit Protection) to default on, no Cygwin programs that rely on the > Cygwin dll would start, stating that a resource was temporarily unavailable > and could not fork. Rebasell, bash, you name it crashed and would not start. > After some investigation, turning off that setting allows Cygwin to work. > > > > Now the next question: why does this not work? Is this intended behavior or > a bug? Having that setting turned on seems like a good idea from a security > standpoint, and who knows it may eventually become default. > > > > Regards, > > Alexandria C. > > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: Mandatory ASLR breaks Cygwin - Windows 10
That's unfortunate. Is there any plans to implement a workaround in the future? Seeing as Cygwin is only one of two programs I've noticed that are broken with it on, it would be nice to be able to have it on from a security perspective. -Original Message- From: Eliot Moss Sent: Tuesday, August 25, 2020 10:35 AM To: Alexandria Cortez Cc: cygwin@cygwin.com Subject: Re: Mandatory ASLR breaks Cygwin - Windows 10 It’s intentional; too long to explain in detail on phone, but fork requires each dll to load in the child at the same address as in the parent, and ASLR interferes with achieving that. Sent from my iPhone > On Aug 25, 2020, at 10:17 AM, Alexandria Cortez wrote: > > I was experimenting with security settings this morning on windows, and > after changing Mandatory ASLR (Windows Security -> App and Browser Control > -> Exploit Protection) to default on, no Cygwin programs that rely on the > Cygwin dll would start, stating that a resource was temporarily unavailable > and could not fork. Rebasell, bash, you name it crashed and would not start. > After some investigation, turning off that setting allows Cygwin to work. > > > > Now the next question: why does this not work? Is this intended behavior or > a bug? Having that setting turned on seems like a good idea from a security > standpoint, and who knows it may eventually become default. > > > > Regards, > > Alexandria C. > > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mandatory ASLR breaks Cygwin - Windows 10
On 2020-08-25 08:36, Alexandria Cortez wrote: > On Tuesday, August 25, 2020 10:35 AM, Eliot Moss wrote:>> On Aug 25, 2020, at > 10:17 AM, Alexandria Cortez wrote: >>> I was experimenting with security settings this morning on windows, and >>> after changing Mandatory ASLR (Windows Security -> App and Browser Control >>> -> Exploit Protection) to default on, no Cygwin programs that rely on the >>> Cygwin dll would start, stating that a resource was temporarily unavailable >>> and could not fork. Rebasell, bash, you name it crashed and would not start. >>> After some investigation, turning off that setting allows Cygwin to work. >>> >>> Now the next question: why does this not work? Is this intended behavior or >>> a bug? Having that setting turned on seems like a good idea from a security >>> standpoint, and who knows it may eventually become default. >> It’s intentional; too long to explain in detail on phone, but fork >> requires each dll to load in the child at the same address as in the >> parent, and ASLR interferes with achieving that. > Is there any plans to implement a workaround in the future? Seeing as Cygwin > is only one of two programs I've noticed that are broken with it on, it > would be nice to be able to have it on from a security perspective. Cygwin is an all-volunteer project - Someone Has To Do It! Feel free to submit patches to support that in Cygwin under Windows. A low level understanding of details of both is required. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: [cygwin] Re: Mandatory ASLR breaks Cygwin - Windows 10
> -Original Message- > From: Brian Inglis > Sent: Tuesday, August 25, 2020 11:13 AM > > On 2020-08-25 08:36, Alexandria Cortez wrote: > > On Tuesday, August 25, 2020 10:35 AM, Eliot Moss wrote:>> On Aug 25, 2020, > > at 10:17 AM, Alexandria > Cortez wrote: > >>> I was experimenting with security settings this morning on windows, and > >>> after changing Mandatory ASLR (Windows Security -> App and Browser Control > >>> -> Exploit Protection) to default on, no Cygwin programs that rely on the > >>> Cygwin dll would start, stating that a resource was temporarily > >>> unavailable > >>> and could not fork. Rebasell, bash, you name it crashed and would not > >>> start. > >>> After some investigation, turning off that setting allows Cygwin to work. > >>> > >>> Now the next question: why does this not work? Is this intended behavior > >>> or > >>> a bug? Having that setting turned on seems like a good idea from a > >>> security > >>> standpoint, and who knows it may eventually become default. > > >> It’s intentional; too long to explain in detail on phone, but fork > >> requires each dll to load in the child at the same address as in the > >> parent, and ASLR interferes with achieving that. > > Is there any plans to implement a workaround in the future? Seeing as Cygwin > > is only one of two programs I've noticed that are broken with it on, it > > would be nice to be able to have it on from a security perspective. > Cygwin is an all-volunteer project - Someone Has To Do It! > Feel free to submit patches to support that in Cygwin under Windows. > A low level understanding of details of both is required. Some relevant reading https://stackoverflow.com/questions/8171298/is-address-space-layout-randomization-applied-on-a-forked-process Is Address Space Layout Randomization applied on a forked process Q: Say I fork a process from another process. Will Address Space Layout Randomization (ASLR) be applied on it in an OS which has ASLR set? Note that I am talking about the case where I don't call execve function after doing fork. A: 12 Yes. However note that after fork both parent and child have the same randomization applied to them (they are copies of each other after all!). If the child and parent are to call mmap(NULL, ...), then their address maps will start to diverge. Update: > Isn't your statement contradictory? Not at all. Immediately after fork, the parent and child address spaces are identical (that's the definition of what fork does). But the ASLR is still in effect for both the parent and the child. The randomization can't "go back in time" and randomize decisions that have already been made, but any future decisions (such as where to place next mmap) will be randomized, and will likely result in different outcome for parent and child. > Does it have to do with basic mmap or OS writers introduce randomness in mmap > as well for security? Perhaps you don't understand what ASLR is? In short, with ASLR on, the OS will randomize placement of main stack, and placement of any non-MAP_FIXED mmaps. By the time you fork, the main stack placement has long been determined, so parent and child will have the same. The future mmap are the only things that can (and will be) affected by ASLR going forward. https://cygwin.com/cygwin-ug-net/highlights.html Process Creation The fork call in Cygwin is particularly interesting because it does not map well on top of the Win32 API. This makes it very difficult to implement correctly. Currently, the Cygwin fork is a non-copy-on-write implementation similar to what was present in early flavors of UNIX. As the child process is created as new process, both the main executable and all the dlls loaded either statically or dynamically have to be identical as to when the parent process has started or loaded a dll. While Windows does not allow to remove binaries in use from the file system, they still can be renamed or moved into the recycle bin, as outlined for unlink(2) in the section called “File Access related changes”. To allow an existing process to fork, the original binary files need to be available via their original file names, but they may reside in a different directory when using the DotLocal (.local) Dll Redirection feature. Since NTFS does support hardlinks, when the fork fails we try again, but create a private directory containing hardlinks to the original files as well as the .local file now. The base directory for the private hardlink directory is /var/run/cygfork/, which you have to create manually for now if you need to protect fork against updates to executables and dlls on your Cygwin instance. As hardlinks cannot be used across multiple NTFS file systems, please make sure your executable and dll replacing operations operate on the same single NTFS file system as your Cygwin instance and the /var/run/cygfork/ directory. Note that this private hardlink directory also does help for when a wrong dll
Re: [cygwin] Re: Mandatory ASLR breaks Cygwin - Windows 10
Following up ... One possible practical direction than can ameliorate this in some cases, and more importantly, perhaps speed up creation of child processes, would be to support posix_spawn more directly under Cygwin. Right now, it does fork and then adjusts things, incurring all the problems and overheads of fork. The full generality of posix_spawn would be hard to do in a more direct (non-fork) manner. It _may_ be possible to handle the simplest cases. posix_spawn is. roughly, fork + exec, meaning the newly forked child is going to get replaced anyway. However, a number of things can be adjusted in this procedure, described by additional arguments to posix_spawn. It might be that the most common and straightforward cases could be done directly, split off from the current, general case. However, the implementers suggest that even this would involve a lot of effort People also ask: Can't we get the Windows team just to support fork? The answer has been consistently "no". WSL (Windows Subsystem for Linux) version 1 appears to implement fork similarly to Cygwin - in any case, it incurs similar overheads. They are able to exploit some private interface, I believe, that avoids Cygwin's hassles with ASLR, but I don't really know. Fork performance under WSL1 is comparable to fork's performance in Cygwin. Meanwhile, WSL version 2 runs under a hypervisor and thus implements its own fork directly, giving speeds more like Linux (a _lot_ faster). Hence it is clear that the Windows OS team do not intend to support fork - they'd just say "use a hypervisor". And of course the way WSL 2 uses hypervisor technology is inside out to the way VirtualBox (etc.) virtualizes hardware, which means that VirtualBox essentially doesn't work (at least not reliably and with good performance) when Windows hardware virtualization is turned on. (I went through a whole long deal to figure out how to really, really, turn it off so that I can run VirtualBox, which I need for other purposes. And of course doing so defeats some of Microsoft's more recent OS additions to improve security.) Hope some of these tidbits are helpful in understanding the situation - one of longstanding frustration to Cygwiners, but not the fault of our excellent volunteer support team! Regards - Eliot Moss -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Race condition hangs on multiple mintty/tcsh? Brad Wetmore
Just installed the latest cygwin (3.1.7-1), and my issue seems to be solved. Thanks to Thomas, Kevin, Corinna, and Takashi for looking in it. Brad From: Brad Wetmore Sent: Wednesday, August 12, 2020 8:08 PM To: cygwin@cygwin.com Subject: Re: Race condition hangs on multiple mintty/tcsh? Brad Wetmore Hi Carinna/Thomas/Takashi, > > > > > > Does anybody familiar with pty/select or recent changes have any > > > > > > idea? > > > > > > > > I looked into this problem. After much struggle, I think > > > > I have found a workaround for this issue. > > > > > > > > I am not sure why this solves the issue at all, however, > > > > this works for me. > > > > > > > Could you please test a patch attached? > > > > > > Shall I commit the patch and create a developer snapshot for testing? > > > > Thanks so much. That would be more convenient for potential testers. > > Done. Please try the latest snapshot from https://cygwin.com/snapshots/ Thanks all for looking into this. I dropped the .dll into my c:\cygwin64\bin directory and wasn't able to reproduce over 5 reboots. The minute I put back the original .dll, it failed again. Let me know if there's anything else I can do to help. Best to you all, Brad From: Brad Wetmore Sent: Thursday, August 6, 2020 12:25 PM To: cygwin@cygwin.com Subject: Re: Race condition hangs on multiple mintty/tcsh? Brad Wetmore Thomas Wolff wrote: > You had previously reported the issue without ssh involved. Does this > make it reproducible more often? Otherwise let's not make things > unnecessarily complicated. I didn't mention it originally because I didn't expect that would have an impact, but then I successfully tried 4 times with the ssh-agent/sleep 3. That's when I sent the email with what seemed to be a good workaround. But after trying it the 5th time following your email, 1 of the 10 didn't pass. 🙁 I took out the ssh, and am seeing it there too, so that was not the issue. Drat. So the delay helped, but didn't completely solve the problem. I have been stalling before starting the cygwin termincal/script for some minutes after a reboot, but that doesn't seem to make a difference either. I can send you the script if you want to play with it. Brad -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Getting an SSH key
Hello, I am using a remote mac called macincloud. I am connected to a server, but I am having a hard time getting an SSH key. I am using unreal engine. In my command prompt I get the error "WARNING: Couldn't compute FAST _CWD pointer. Then it tells me to contact this email address. I'm not sure how to fix this problem. Thank you, Kyra -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Build of glm-0.9.7.6-1-src.tar.xz does not work.
Hello, thank you very much, your updated script allowed me to complete the rebuilt process. KiCad requires GLM version 0.9.8 or newer for compiling. Unfortunately, I discovered that just replacing the old sources with the latest ones is not enough for updating the library. Since version 0.9.9.6, the install and uninstall targets have been removed from generated Makefile: https://github.com/g-truc/glm/commit/5f352ecce21bb1ab37fa56fac0f383c779b351a3#diff-af3b638bc2a3e6c650974192a53c7291 So, the current cygport script is able to work up to version 0.9.9.5, which is enough for the task anyways. Perhaps, the newer versions are using CMake directly for doing installation, but I have no idea how this is expected to work in cygport. Thank you very much for your time and your support. Sincerely, Il giorno dom 23 ago 2020 alle ore 18:04 Marco Atzeri via Cygwin ha scritto: > > On 23.08.2020 17:30, Jon Turney wrote: > > On 22/08/2020 06:00, Marco Atzeri via Cygwin wrote: > >> On 21.08.2020 10:35, Carlo B. via Cygwin wrote: > >>> Hello, > >>> I tried to rebuild glm-0.9.7.6-1-src.tar.xz but the "install" command > >>> does not work. > >>> I'm getting this error message: > >>> > >> Installing glm-0.9.7.6-1.noarch > >>> make: *** Nessuna regola per generare l'obiettivo «install». Arresto. > >>> *** ERROR: make install DESTDIR failed > >>> > >>> Translated in english, it should be something like this: > >>> "No rules to generate target <>. Stop." > >>> > > [...] > >> > >> the error is caused by the build system using now cmake+ninja for > >> the execution > >> > >> while mingw64-i686-glm and mingw64-x86_64-glm builds stay on the > >> previous cmake+make > >> > > I am a bit confused by this. What causes the default generator used by > > cmake to change? Having old .cygports break due to that seems bad. > > > > not sure. > I guess that if ninja is available the glm cmake settings > give it a precedence. > > It is also possible that the latest cmake is behaving differently > than previous one. > > Regards > Marco > > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [cygwin] Re: Mandatory ASLR breaks Cygwin - Windows 10
On 2020-08-25 09:56, Eliot Moss wrote: > Meanwhile, WSL version 2 runs under a hypervisor and thus implements its own > fork directly, giving speeds more like Linux (a _lot_ faster). Hence it is > clear that the Windows OS team do not intend to support fork - they'd just say > "use a hypervisor". Good advice which I took, and find running a lightweight distro in a VM gets near native performance, without worrying about what MS "Linux" or Windows does or supports, plus you can use multiple processes, with X and all services, without limits other than those applied to the VM: "Those who do not understand Unix are condemned to reinvent it, poorly." -- Henry Spencer -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Issue on output when using javac or scalac under emacs
trace_w32 Description: Binary data trace_nox Description: Binary data trace_nt Description: Binary data -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: [cygwin] Issue on output when using javac or scalac under emacs
> -Original Message- > From: Luc Henninger > Sent: Tuesday, August 25, 2020 6:40 PM > I'm thick - what the issue? There was no body to the email. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Issue on output when using javac or scalac under emacs
Dear Luc -- You should be aware that while Cygwin can invoke Java, the Windows Java still expects _Windows-style_ arguments, including Windows paths, etc. For example, not a/b/c:d/e but 'a\b\c;d\e" for a path. Just because you're using Cygwin, the installed Java is not "magically" transported to the Linux world! You may also run into issues around line endings (CR/LF vs LF only, and so forth). Regards - Eliot Moss -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [cygwin] Issue on output when using javac or scalac under emacs
On 2020-08-25 17:19, Jason Pyeron wrote: >> -Original Message- >> From: Luc Henninger >> Sent: Tuesday, August 25, 2020 6:40 PM >> > > I'm thick - what the issue? There was no body to the email. There were three attachments with javac complaining about a missing symbol, but it is unclear under what conditions which product produced each of the outputs, what output was expected, and what was the issue with what was actually output? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Issue on output when using javac or scalac under emacs
On 2020-08-25 18:36, Eliot Moss wrote: > Dear Luc > You should be aware that while Cygwin can invoke Java, the Windows Java still > expects _Windows-style_ arguments, including Windows paths, etc. > > For example, not a/b/c:d/e but 'a\b\c;d\e" for a path. > > Just because you're using Cygwin, the installed Java is not "magically" > transported to the Linux world! > > You may also run into issues around line endings (CR/LF vs LF only, and so > forth). Many Windows APIs and programs accept either path separator and in such cases there are seldom issues as long as the paths are not too long e.g. try: $ /proc/cygdrive/c/Windows/System32/icacls path/with/slash/delimiters and many programs, including editors and terminals, do a good job of adapting to line endings, including mintty and less. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.] -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Issue on output when using javac or scalac under emacs
Agreed that / vs \ is sometimes no problem. I do know that Windows Java really wants ; and not : when giving multiple path names ... EM Sent from my iPhone > On Aug 25, 2020, at 10:50 PM, Brian Inglis > wrote: > > On 2020-08-25 18:36, Eliot Moss wrote: >> Dear Luc >> You should be aware that while Cygwin can invoke Java, the Windows Java still >> expects _Windows-style_ arguments, including Windows paths, etc. >>> For example, not a/b/c:d/e but 'a\b\c;d\e" for a path. >> >> Just because you're using Cygwin, the installed Java is not "magically" >> transported to the Linux world! >> >> You may also run into issues around line endings (CR/LF vs LF only, and so >> forth). > > Many Windows APIs and programs accept either path separator and in such cases > there are seldom issues as long as the paths are not too long e.g. try: > >$ /proc/cygdrive/c/Windows/System32/icacls path/with/slash/delimiters > > and many programs, including editors and terminals, do a good job of adapting > to > line endings, including mintty and less. > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in IEC units and prefixes, physical quantities in SI.] > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [cygwin] Issue on output when using javac or scalac under emacs
Le 26/08/2020 à 01:19, Jason Pyeron a écrit : -Original Message- From: Luc Henninger Sent: Tuesday, August 25, 2020 6:40 PM I'm thick - what the issue? There was no body to the email. Hello, ( My previous message dos not contain the text, only the attachments!!! ) For years, I use emacs-nt (the one provided by gnu.org) under cygwin. I just discover that emacs is also directly provided by cygwin (late is better than never :-)). So I try to use it successfully up to a compilation error in one of my program in java. To compile java (or scala), I use my own makefile that I start from emacs. In case of error, I encountered a strange output undex emacs_w32 and emacs_nox compared to emacs_nt (see trace_nox, trace_w32 and trace_nt in attachment). I currently use emacs release 27.1 for all emacses, but I verify that I have the same strange behaviour with emacs 26.3. Can anybody explain this? and more gane give a workaround? Regards -- luc.hennin...@orange.fr+33 6 32 96 32 27 -- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Issue on output when using javac or scalac under emacs
Le 26/08/2020 à 02:36, Eliot Moss a écrit : Dear Luc -- You should be aware that while Cygwin can invoke Java, the Windows Java still expects _Windows-style_ arguments, including Windows paths, etc. For example, not a/b/c:d/e but 'a\b\c;d\e" for a path. Just because you're using Cygwin, the installed Java is not "magically" transported to the Linux world! You may also run into issues around line endings (CR/LF vs LF only, and so forth). Regards - Eliot Moss Thanks, but I already use "cygpath" within my makefiles in case of "java" to convert file paths. Regards -- luc.hennin...@orange.fr+33 6 32 96 32 27 -- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
