Windows 10 Creators Update and Symlinks
When Developer mode is enabled the elevation requirement for symlink creation is disabled: https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/#DXz6icKZOkEozgYR.97 This was necessary for symlink creation within WSL to work. smime.p7s Description: S/MIME Cryptographic Signature
Re: Use a default path in exec*p*() if PATH is unset?
On 4/12/2017 12:41 PM, Christian Franke wrote: > cyg Simple wrote: >> ... >> But I don't believe that env --ignore-environment should be using execvp >> and should be using execv instead. That is for the upstream coreutils >> team to decide though. > > Possibly not, as it would also require to check whether PATH is set > later in the command line. > > Always using execv() if -i is specified would break: > > env -i PATH=/bin:/usr/bin prog > Good! --ignore-environment is just that regardless of where the environment is set. > To force execv()-like behavior with -i, simply use > > env -i PATH=. prog > But this is what should occur anyway. -- cyg 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: Use a default path in exec*p*() if PATH is unset?
cyg Simple wrote: ... But I don't believe that env --ignore-environment should be using execvp and should be using execv instead. That is for the upstream coreutils team to decide though. Possibly not, as it would also require to check whether PATH is set later in the command line. Always using execv() if -i is specified would break: env -i PATH=/bin:/usr/bin prog To force execv()-like behavior with -i, simply use env -i PATH=. prog Christian -- 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: Use a default path in exec*p*() if PATH is unset?
On 4/11/2017 3:02 PM, Christian Franke wrote: > cyg Simple wrote: >> >>-i, --ignore-environment start with an empty environment >> >> A relative use of the executable will not be found if the environment is >> empty. > > Not necessarily (see Linux, *BSD, ...). POSIX says this is > "implementation-defined" - under the assumption that 'env' uses execvp() > which is the case for the GNU coreutils version. > > POSIX says this is "implementation-defined" Which means it is undefined by POSIX. Also one could argue that --ignore-environment also means any default ones within an API set. > >>> Interestingly the approach in newlib/libc/posix/execvp.c differs from >>> Cygwin and others: >>> execvp() with PATH unset calls execv(). This has the same effect as >>> execvp() with PATH set to current directory only. >>> >> Why do you assume that this is an issue with execvp? > > I never did (otherwise this would be a thread on cygwin-patches list). > > The above only means that it is IMO interesting that the Cygwin source > package contains two implementations of execvp() which handle the unset > PATH situation differently. > Sure, but it is implemented correctly based on POSIX. ;) > >> The user should >> not expect that an undefined behavior behaves the same way on other >> systems. > > Of course. But even then it is a reasonable question which possible > alternative should be implemented by Cygwin. Cygwin homepage says "Get > that Linux feeling, ...". So "implementation-defined" behavior should > possibly be close to Linux :-) > Even so not all "Linux feeling" can be implemented. But I agree it should be as close as possible. But I don't believe that env --ignore-environment should be using execvp and should be using execv instead. That is for the upstream coreutils team to decide though. -- cyg 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: man page of CYGPORT(1) has an old content. should be updated.
On 2017-04-11 22:25, dodo . wrote: > Hello, > > I report one thing about manpage for cygport. > > Man page CYGPORT(1) seems to show old content about 'all' COMMAND. > According to manpage CYGPORT(1), 'all' COMMMAND means 'run all of > the above, excluding finish.' > However 'download' COMMAND is excepted on actual performing. > Thus, source patching with $(PATCH_URI} does not perform. > > Latest README of cygport describes correct information. > https://github.com/cygwinports/cygport/blob/master/README > According to it, fetch(download) COMMAND is not included in 'all'. > > I think manpage CYGPORT(1) should be updated. > > Currently I am using Cygwin as follows. > > $ uname -a > CYGWIN_NT-6.1-WOW turtle0 2.8.0(0.309/5/3) 2017-04-01 20:42 i686 Cygwin > > $ cygport --version > cygport 0.24.0 > ... Also available in /usr/share/doc/cygport/README, and the full manual from by launching or running: $ cygstart /usr/share/doc/cygport/html/manual/index.html but those, usage, and manpage all omit some options, commands and alternatives, and do not state the preconditions necessary for commands to work, nor that steps already completed are skipped if the command is almostall|all. >From the current source, supported options are: --help|-h|-? --version|-v --debug|-d --32|-4 --64|-8 and commands are: downloadall|fetchall|wgetall|getall download|fetch|wget|get prep|unpack compile|build|make check|test inst* postinst* list dep* info* homepage|web*|www* package|pkg diff|mkdiff|mkpatch upload|up announce clean|finish almostall|all help version -- 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
