please send me this mail
Hello Sir Please include me this list. I use Cygwin quite a bit. Thanks Srinivasa Charlu 703-991-9515 cell -- 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: Problem with tar version 1.29 (in Cygwin 3.6 64 bit) in extracting sym-link files
On 05/10/2020 18:29, Brian Inglis wrote: > On 2020-10-05 09:23, Hamish McIntyre-Bhatty via Cygwin wrote: >> On 04/10/2020 11:28, Andrey Repin via Cygwin wrote: >>> Greetings, vinay Hegde! >>> >>> Please no top-posting in this list. >>> On Fri, Oct 2, 2020 at 9:13 PM Eliot Moss wrote: > On 10/2/2020 11:26 AM, vinay Hegde via Cygwin wrote: >> Hi Cygwin Team, >> In Cygwin 3.6, I am facing an issue while using tar.exe for extracting >> .tar.z file. >> >> Issue summary: >> When I use 'tar.exe' to extract the .tar.z file, it extracts all files >> including symlinks. But symlink file size will be 0KB & it throws >> error 'The file cannot be accessed by the system', if I try to open in >> any Windows editor like notepad or notepad++ >> >> Below are the details: >> - OS: Windows 2019 >> - Cygwin version installed: 3.6 (tar version: 1.29) >> - Command used to extract the tar file is: tar -zxvf jre64.tar.Z >> - 'ls -l' on the extracted directory shows: >> lrwxrwxrwx 1 etbuild Domain Users 8 Jul 10 2017 ControlPanel -> >> jcontrol >> -rwxr-xr-x+ 1 etbuild Domain Users 7734 Mar 15 2017 java >> -rwxr-xr-x+ 1 etbuild Domain Users 128791 Mar 15 2017 javaws >> -rwxr-xr-x+ 1 etbuild Domain Users 6264 Mar 15 2017 jcontrol >> >> - As you can see 'ControlPanel' is a symlink file with 0KB >> (8Bytes) size. This file, I cannot open in any Windows editor. It >> throws error like ''The file cannot be accessed by the system' >> >> -However, I can open this file in vi editor or I can 'cat' this. >> >> -Earlier, I was using Cygwin version 1.7 (tar version: 1.27) & in >> that, this issue was not there. Symlink file size was 1KB & I could >> open it with any Windows editor. >> >> Please suggest what needs to be done to fix this issue. > Hi, Vinay - Cygwin can use, and create, a variety of forms of links. > Some of these are understood > by Windows tools, some not. I suggest you read in the Cygwin > documentation about symlinks and > decide what kind are best for you. Then you'll need to set that up, > delete the existing link, and > re-create it. I personally run with CYGWIN=winsymlinks:native, but as we > say in Internet land, YMMV. > Hi Eliot Moss, Thank you very much for the quick response & the information.It really helped. I just set 'CYGWIN=winsymlinks:lnk' & I am now able to open sym-link file. Both 'CYGWIN=winsymlinks:lnk' & 'CYGWIN=winsymlinks' are working for me. But it creates a shortcut(not the regular file). Hope it won't impact my existing setup. But both 'CYGWIN=winsymlinks:native' (which is default I believe) & 'CYGWIN=winsymlinks:nativestrict' are not working for me. Just to understand, In what OS environment/File System 'native' will work? >>> Given enough permissions, "native" will work everywhere, it will create >>> native >>> symlink, but failing that, it will fall back to creating Cygwin link. >>> >>> LNK is an Explorer shortcut, which would work with many programs outside >>> Cygwin, but not necessarily with your one. >>> >>> See https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks as well >>> as >>> https://cygwin.com/cygwin-ug-net/using-cygwinenv.html >> Does anyone happen to know if there's a way to automatically regenerate >> existing symlinks after changing these settings? > Example: remove the "echo" after checking it will update only the desired > links: > > $ for link in `find . -type l` >> do >> targ=`readlink $link` >> echo ln -fsv $targ $link >> done > ln -fsv linux-kernel/linux-next/cpufeatures.h ./cpufeatures.h > ln -fsv linux-kernel/linux-next/cpufeatures.log ./cpufeatures.log > ln -fsv ../../cygwin/newlib-cygwin/winsup/cygwin/fhandler_proc.cc > ./cpuinfo/fhandler_proc.cc > ln -fsv ../../cygwin/newlib-cygwin/winsup/cygwin/sysconf.cc > ./cpuinfo/sysconf.cc > ln -fsv ../cygwin/cpuid ./cygwin > ln -fsv CPUID_Explorer/CPUID/Debug Static/CPUID.exe ./explorer > ln -fsv /lib/gcc/x86_64-pc-cygwin/9.3.0/include/cpuid.h ./gcc/cpuid.h > ln -fsv linux-kernel/linux-prev-next.diff ./linux-prev-next.diff > ln -fsv linux-kernel/linux-next/scattered.log ./scattered.log Cheers, worked for me. In my case, I'm bundling Cygwin in an installer package for one of my programs, so I used this trick to regenerate all my Cygwin symlinks as Windows .lnk files (using 32-bit Cygwin to run that on C:\cygwin64 and vice versa). I'm aware that it was probably Not Recommended (TM) to do that so I made backups first. All seems fine so far. I was having problems with the bundles and I figured Cygwin might be using WSL symlinks (my dev VM is running Windows 10), so I thought it was worth a try. Cheers. Hamish 0x87B761FE07F548D6.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- Problem reports:
Re: Unconsistent command-line parsing in case of UTF-8 quoted arguments
Thanks for your reply. Andrey Repin wrote: > 1. Run CMD in a more capable terminal. Either M$ Terminal 1.0, or select true > type font for your console. I tried Windows Terminal 1.3, but this did not change anything :-( Besides, I think my cmd.exe was already using True Type fonts (if I understand the icons from the settings window correctly) Anyway, I now understand that the terminal I use matters. In my case however, I do not intend to run the binary (built with Cygwin) in a terminal at all. I am using win-sshfs [2]. It is built from Cygwin, but it is then used as a standalone executable, without any GUI. It is called by a Windows component/driver (with a command line that contains quoted UTF-8 arguments), invoked by some clicks and actions from the 'My computer' window. What could I do so that this program correctly handles the command line? > 2. Then you are parsing the command line wrong. In Windows, it is up to called > program to parse the command line. Right, but my program starts at `int main(int argc, char *argv[])`, where the parsing is already handled (by some Cygwin runtime component?). How could I parse it differently? And would that even make sense that I parse it in a custom way? Since -I suppose- every C program built by Cygwin faces the same issues, wouldn't we rather want a "universal" change on how the Cygwin runtime parses command lines? For the record, this is what I have done in this program [1], but that feels more like a work around some UTF-8-related bug than a proper, custom command line parsing :-S ...or maybe I'm completely mistaken in how Cygwin works, in case I'd be happy to be told :-) [1] https://github.com/billziss-gh/sshfs-win/pull/208 [2] https://github.com/billziss-gh/sshfs-win Thanks for your help Jérôme -- 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: Unconsistent command-line parsing in case of UTF-8 quoted arguments
On 2020-10-06 23:17, Thomas Wolff wrote: > > > Am 06.10.2020 um 23:36 schrieb Jérôme Froissart: >> Thanks for your replies. >> This issue only happens when a program is run from cmd.exe, not from a >> Cygwin bash shell. >> This is important for me, since I discovered this bug in a project >> that must be run from Windows graphical shell (i.e. there is no >> sensible way to run it through Cygwin and Bash). >> >>> Please show us the output from "uname -a" and "locale" run from the bash >>> prompt. >> Running it from the same Cygwin bash prompt works as expected >> $ uname -a >> CYGWIN_NT-10.0 XPS 3.1.5(0.340/5/3) 2020-06-01 08:59 x86_64 Cygwin > Please update to cygwin 3.1.7; there were issues about command line quoting > before, I'm not sure whether there was a tweak since 3.1.5 already. [PATCH] Cygwin: console: Replace WriteConsoleA() with WriteConsoleW(): https://cygwin.com/pipermail/cygwin-patches/2020q3/010495.html [PATCH v4 1/3] Cygwin: rewrite and make public cmdline parser: https://cygwin.com/pipermail/cygwin-patches/2020q3/010577.html Issues raised and no v5 response so far -- 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 binary 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: Unconsistent command-line parsing in case of UTF-8 quoted arguments
I think what we mean is that, under Windows cmd, some things the shell does for you under Linux and Cygwin will not have been done. For example, there is "glob" expansion of filenames. If I write *.txt under bash, it gets expanded to a space-separated list of names of files that match that pattern. This happens _before_ calling my program. If the program is run from Windows cmd.exe, the program will receive an argument *.txt, and it will have to do the "globbing" itself. Etc. 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: Unconsistent command-line parsing in case of UTF-8 quoted arguments
On 2020-10-07 18:59, Eliot Moss wrote: > I think what we mean is that, under Windows cmd, some things the shell does > for > you under Linux and Cygwin will not have been done. For example, there is > "glob" expansion of filenames. If I write *.txt under bash, it gets expanded > to > a space-separated list of names of files that match that pattern. This > happens > _before_ calling my program. If the program is run from Windows cmd.exe, the > program will receive an argument *.txt, and it will have to do the "globbing" > itself. Etc. That's handled automatically by the Cygwin program startup command line parser if it is not passed a "Cygwin" command line: that avoids the startup expanding quoted args that contain wildcards passed from another Cygwin program or shell. -- 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 binary 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: please send me this mail
On 2020-10-07 14:05, Charlu, Srinivasa [US] (MS) via Cygwin wrote: > Please include me this list. I use Cygwin quite a bit. Follow link at bottom and directions there to unsubscribe or *subscribe*. > -- > 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 These lists use an automated challenge response system to validate subscriptions to all mailing lists which are managed automatically on the host site. -- 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 binary 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
