Cygwin64, 'unzip -d' misbehaviour vs. Cygwin32

[Wladimir Mutel]

Dear all,

I have a .zip archive on a different NTFS filesystem than Cygwin64 TMP
folder (say, .zip on I: and TMP on C:). I create a temporary folder
by 'mktemp -d' and then try to unpack .zip archive into that folder :
unzip -d $folder $archive
I notice that files are unpacked into I:\TMP\ folder instead of
C:\Cygwin64\tmp\ (unzip recreates temporary subfolder with same name
inside I:\TMP\, while initial subfolder under c:\cygwin64\tmp\
remains empty)
Trying to work around this problem, I do this :
p=$(pwd)/$archive # archive is relative path under /cygdrive/i/ ,
  # so I construct abs.path
( cd $folder
  unzip $p ) # in subshell to keep current pwd unchanged
Then I get a message like :
unzip:  cannot find either /cygdrive/i/path/archive.zip or 
/cygdrive/i/path/archive.zip.zip.


	Even more, unzip -v /cygdrive/i/path/archive.zip invariably fails in this way 
under Cygwin64. What I see is that unzip accepts only relative paths for archive 
files. And that it improperly handles specified unpack directory (-d).


	No such problems are observable under Cygwin32. unzip works exactly as 
specified with both absolute and relative paths, as well as with unpack folder 
on different filesystem from .zip archive.


Please try to reproduce my findings and fix them on Cygwin64 side
or tell me how could I fix them myself (if it is my personal problem).

Thanks in advance for your help.

--
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

Native symbolic links to non-existent targets (possible bug?)

[Brian Ericson]

Cygwin appears to ignore "winsymlinks:native" when asked to create a 
symbolic link to a non-existent target, reverting to its "magic header" 
approach.


This can be demonstrated via the following examples (using a Cygwin shell):
  echo hello > aaa
  ln -s aaa bbb
  notepad bbb

  ln -s xxx yyy
  notepad yyy

"notepad bbb" will show "hello", but "notepad yyy" produces "㰡祳汭湩 
㹫xxx ".  "bbb" is a native symbolic link, "yyy" is not.  (This can 
also be confirmed using "dir" (cmd.exe /c dir from within Cygwin) or 
looking for the curved arrow glyph in the folder explorer.)


Note that this is in contrast to mklink (using a command prompt):
  echo hello > 
  mklink  
  notepad 

  mklink  
  notepad 

In this case, both mklink commands succeed; "notepad " works as 
expected, and "notepad " pops up an alert with "Cannot find the  
file. Do you want to create a new file?", which makes sense (it even 
writes to  if you say "yes").


Also, mklink-created symbolic links to non-existent targets appear to 
work (just as they do on *nix) when the non-existent target is created:

  echo hello again > 
  notepad 

The result is now "hello again".

I initially stumbled upon this discrepancy in the following real-world 
example:

  git init foo
  cd foo
  touch .gitignore
  git add .gitignore
  git commit -m 'first commit'
  git checkout -b links
  mkdir -p a/b
  echo hello > a/file_in_a
  ln -s ../file_in_a a/b/link_to_file_in_a
  git add a
  git commit -m 'Added symbolic link'

At this point, we have a valid, native symbolic link, which can be 
confirmed using notepad as before:

  notepad a/b/link_to_file_in_a

We run into problems, however, when we do the following:
  git checkout master && git checkout links

Git will create the symbolic link *before* it creates the target, and 
the result is a non-native file.  "notepad a/b/link_to_file_in_a" now 
produces "㰡祳汭湩㹫../file_in_a ".


Shouldn't Cygwin honor "winsymlinks:native" even with the target does 
not exist?


I'm using Cygwin 6.1.

--
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] Updated: bash-4.1.13-6

[Eric Blake]

On 09/29/2014 04:52 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
>> These functions contain '-' in their name; that's a limitation of
>> the downstream forked patch I applied early to get 4.1.13-6 out the
>> door. Upstream solved it in a nicer manner, so you can once again have
>> functions with '-' in the name. Please try again with the just-released
>> 4.1.14-7.
> 
> I understand that to mean that 4.1.14-7 will be able to export functions with 
> '-' in
> their names.

Correct; also, I already verified it worked locally for me to export a
function with '-' when using 4.1.14-7.

> 
>>> I was able to get rid of this by commenting out the functions (make-log,
>>> configure-log, and prt-alias) and removing them from the list of functions 
>>> being
>>> set and exported in ~/.bashrc.  I rarely use these functions and would be 
>>> unlikely
>>> to use them in a subshell so that works as a solution.
>>
>> Having the function wasn't the problem, it was exporting it. You can
>> still have the function even in 4.1.13-6, as long as you don't export
>> it.
> 
> Changed to underscores.  All is well.

Also an option. :)

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Bug] C-n keybinding doesn't work with GNU texinfo (Windows 6.1.7601 64bit)

[Ken Brown]

On 9/29/2014 4:05 PM, Ken Brown wrote:

Unfortunately, Cygwin's Texinfo package currently lacks a maintainer.


I'm willing to take over as maintainer.  I'll send an ITP to cygwin-apps 
shortly.


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: [ANNOUNCEMENT] Updated: bash-4.1.13-6

[Buchbinder, Barry (NIH/NIAID) [E]]

Eric Blake sent the following at Monday, September 29, 2014 5:29 PM
>On 09/29/2014 03:23 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
>> Eric Blake (cygwin) sent the following at Saturday, September 27, 2014 2:14 
>> AM
>>
>> Using the new version of bash, two scripts that I use have both started 
>> giving me
>> the following error message(s).
>>
>> /usr/bin/bash: error importing function definition for `BASH_FUNC_make-log'
>> /usr/bin/bash: error importing function definition for 
>> `BASH_FUNC_configure-log'
>> /usr/bin/bash: error importing function definition for `BASH_FUNC_prt-alias'
>
>These functions contain '-' in their name; that's a limitation of
>the downstream forked patch I applied early to get 4.1.13-6 out the
>door. Upstream solved it in a nicer manner, so you can once again have
>functions with '-' in the name. Please try again with the just-released
>4.1.14-7.

I understand that to mean that 4.1.14-7 will be able to export functions with 
'-' in
their names.

>> I was able to get rid of this by commenting out the functions (make-log,
>> configure-log, and prt-alias) and removing them from the list of functions 
>> being
>> set and exported in ~/.bashrc.  I rarely use these functions and would be 
>> unlikely
>> to use them in a subshell so that works as a solution.
>
>Having the function wasn't the problem, it was exporting it. You can
>still have the function even in 4.1.13-6, as long as you don't export
>it.

Changed to underscores.  All is well.

>> Another thing happening is that some scripts are now sometimes giving this 
>> error
>> message, but only when the problem function exports are not being exported.
>>
>> Segmentation fault (core dumped)
>
>Umm, that's not good. Can you please come up with a minimal reproduction
>formula? Which program is dumping core? Bash, or something else? Is it
>due to trying to execute the function that was not imported?

It wasn't reproducible, but a while after I sent my email various windows 
stopped
responding, I couldn't close them, the machine wouldn't shut down, and ended up
unplugging the machine so I could reboot.  Let's assume that something unrelated
to cygwin was going on.

>> Any hints about what I should look for to make export of my bash shell 
>> functions
>> reliable?
>
>Upgrading to the next version :)

Will do!

Thanks for all your help.

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

[ANNOUNCEMENT] Updated: bash-4.1.14-7

[Eric Blake (cygwin)]

A new release of bash, 4.1.14-7, has been uploaded and will soon reach a
mirror near you; leaving the previous version at 4.1.13-6.

NEWS:
=
This is a minor rebuild which picks up an upstream patch to fix
CVE-2014-7169 and all other ShellShock attacks (4.1.13-6 was also safe,
but used a slightly different downstream patch that used '()' instead of
'%%' in environment variables, and which was overly restrictive on
importing functions whose name was not an identifier).  There are still
known parser crashers (such as CVE-2014-7186, CVE-2014-7187, and
CVE-2014-6277) where upstream will probably issue patches soon; but
while those issues can trigger a local crash, they cannot be exploited
for escalation of privilege via arbitrary variable contents by this
build.  Left unpatched, a vulnerable version of bash could allow
arbitrary code execution via specially crafted environment variables,
and was exploitable through a number of remote services, so it is highly
recommended that you upgrade
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/
https://access.redhat.com/articles/1200223
https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00238.html

I also hope to have a build of bash 4.3 available soon, but wanted to
get the CVE fixed as soon as possible due to its severity.

There are a few things you should be aware of before using this version:
1. When using binary mounts, cygwin programs try to emulate Linux.  Bash
on Linux does not understand \r\n line endings, but interprets the \r
literally, which leads to syntax errors or odd variable assignments.
Therefore, you will get the same behavior on Cygwin binary mounts by
default.
2. d2u is your friend.  You can use it to convert any problematic script
into binary line endings.
3. Cygwin text mounts automatically work with either line ending style,
because the \r is stripped before bash reads the file.  If you
absolutely must use files with \r\n line endings, consider mounting the
directory where those files live as a text mount.  However, text mounts
are not as well tested or supported on the cygwin mailing list, so you
may encounter other problems with other cygwin tools in those directories.
4. This version of bash has a cygwin-specific set option, named "igncr",
to force bash to ignore \r, independently of cygwin's mount style.  As
of bash-3.2.3-5, it controls regular scripts, command substitution, and
sourced files.  I hope to convince the upstream bash maintainer to
accept this patch into a future bash release even on Linux, rather than
keeping it a cygwin-specific patch, but only time will tell.  There are
several ways to activate this option:
4a. For a single affected script, add this line just after the she-bang:
 (set -o igncr) 2>/dev/null && set -o igncr; # comment is needed
4b. For a single script, invoke bash explicitly with the option, as in
'bash -o igncr ./myscript' rather than the simpler './myscript'.
4c. To affect all scripts, export the environment variable BASH_ENV,
pointing to a file that sets the shell option as desired.  Bash will
source this file on startup for every script.
4d. Added in the bash-3.2-2 release: export the environment variable
SHELLOPTS with igncr included in it.  It is read-only from within bash,
but you can set it before invoking bash; once in bash, it auto-tracks
the current state of 'set -o igncr'.  If exported, then all bash child
processes inherit the same option settings; with the exception added in
3.2.9-11 that certain interactive options are not inherited in
non-interactive use.
4e. bash-4.1.9-1 dropped support for 'shopt -s igncr'; it did not make
sense to support the option through both set and shopt, and SHELLOPTS
proved to be more powerful.
5. You can also experiment with the IFS variable for controlling how
bash will treat \r during variable expansion.
6. There are varying levels of speed at which bash operates.  The
fastest is on a binary mount with igncr disabled (the default behavior).
 Next would be text mounts with igncr disabled and no \r in the
underlying file. Next would be binary mounts with igncr enabled.  And
the slowest that bash will operate is on text mounts with igncr enabled.
7. As additional cygwin extensions, this version of bash includes:
7a. EXECIGNORE - a colon-separated list of glob patterns to ignore
when completing on executables.  EXECIGNORE=*.dll is common.
7b. completion_strip_exe - using 'shopt -s completion_strip_exe'
makes completion strip .exe suffixes
8. This version of bash is immune to ShellShock (CVE-2014-6271 and
friends) because it exports functions via 'BASH_FUNC_foo%%=' rather than
'foo=' environment variables.  However, doing this has exposed
weaknesses in some other utilities like 'ksh' or 'at' that fail to scrub
their environment to exclude what is not a valid name for them.
9. If you don't like how bas

Re: [ANNOUNCEMENT] Updated: bash-4.1.13-6

[Eric Blake]

On 09/29/2014 03:23 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> Eric Blake (cygwin) sent the following at Saturday, September 27, 2014 2:14 AM
> 
> Using the new version of bash, two scripts that I use have both started 
> giving me
> the following error message(s).
> 
> /usr/bin/bash: error importing function definition for `BASH_FUNC_make-log'
> /usr/bin/bash: error importing function definition for 
> `BASH_FUNC_configure-log'
> /usr/bin/bash: error importing function definition for `BASH_FUNC_prt-alias'

These functions contain '-' in their name; that's a limitation of the
downstream forked patch I applied early to get 4.1.13-6 out the door.
Upstream solved it in a nicer manner, so you can once again have
functions with '-' in the name.  Please try again with the just-released
4.1.14-7.

> 
> I was able to get rid of this by commenting out the functions (make-log,
> configure-log, and prt-alias) and removing them from the list of functions 
> being
> set and exported in ~/.bashrc.  I rarely use these functions and would be 
> unlikely
> to use them in a subshell so that works as a solution.

Having the function wasn't the problem, it was exporting it.  You can
still have the function even in 4.1.13-6, as long as you don't export it.

> 
> Another thing happening is that some scripts are now sometimes giving this 
> error
> message, but only when the problem function exports are not being exported.
> 
> Segmentation fault (core dumped)

Umm, that's not good. Can you please come up with a minimal reproduction
formula?  Which program is dumping core? Bash, or something else?  Is it
due to trying to execute the function that was not imported?

> 
> Any hints about what I should look for to make export of my bash shell 
> functions
> reliable?

Upgrading to the next version :)


-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

RE: [ANNOUNCEMENT] Updated: bash-4.1.13-6

[Buchbinder, Barry (NIH/NIAID) [E]]

Eric Blake (cygwin) sent the following at Saturday, September 27, 2014 2:14 AM

Using the new version of bash, two scripts that I use have both started giving 
me
the following error message(s).

/usr/bin/bash: error importing function definition for `BASH_FUNC_make-log'
/usr/bin/bash: error importing function definition for `BASH_FUNC_configure-log'
/usr/bin/bash: error importing function definition for `BASH_FUNC_prt-alias'

I was able to get rid of this by commenting out the functions (make-log,
configure-log, and prt-alias) and removing them from the list of functions being
set and exported in ~/.bashrc.  I rarely use these functions and would be 
unlikely
to use them in a subshell so that works as a solution.

What makes this strange is that I have other shell functions that are defined in
~/.bashrc and exported.  They have not shown up in the error messages.  As it
happens, the problem functions are the last 3 on the export list.  However,
adding another function to be exported doesn't cause a new error message for
just one function that is now at the end of the export list.

Another thing happening is that some scripts are now sometimes giving this error
message, but only when the problem function exports are not being exported.

Segmentation fault (core dumped)

Any hints about what I should look for to make export of my bash shell functions
reliable?

Thanks,

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

Re: [Bug] C-n keybinding doesn't work with GNU texinfo (Windows 6.1.7601 64bit)

[Ken Brown]

On 9/29/2014 1:32 PM, Alive wrote:

Here are steps to reproduce the problem.
1. Open cygwin terminal.
2. Type "info info" to display info page about GNU texinfo.
3. Press C-n (CTRL + n) to move the cursor

Expected result: C-n key combination moves the cursor one line down.

Actual result: An error message about unknown command is displayed.
"Unknown command (C-n)."

This malicious behavior isn't reproducible on Ubuntu version of GNU
texinfo. Tested on 14.04.1 with latest updates.


This is actually an upstream bug, which was fixed almost a year ago:


http://svn.savannah.gnu.org/viewvc/trunk/info/infomap.c?root=texinfo&r1=5338&r2=5387

The fix is trivial and was incorporated into the Ubuntu package. 
Unfortunately, Cygwin's Texinfo package currently lacks a maintainer.


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

[Bug] C-n keybinding doesn't work with GNU texinfo (Windows 6.1.7601 64bit)

[Alive]

GNU texinfo normally has emacs keybinding.
I found it strange, because C-n navigation key, which normally moves
cursor down,
doesn't work. C-f, C-b, and C-p works as expected to move cursor one
character
forward, one character backward, and one line backward.
I'm using latest cygwin, from setup-x86_64.exe version 2850, on Windows
6.1.7601
64 bit.

Here is info version
```
info (GNU texinfo) 5.2

Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
```
Here are steps to reproduce the problem.
1. Open cygwin terminal.
2. Type "info info" to display info page about GNU texinfo.
3. Press C-n (CTRL + n) to move the cursor

Expected result: C-n key combination moves the cursor one line down.

Actual result: An error message about unknown command is displayed.
"Unknown command (C-n)."

This malicious behavior isn't reproducible on Ubuntu version of GNU
texinfo. Tested on 14.04.1 with latest updates.

--
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] Updated: bash-4.1.13-6

[Achim Gratz]

Eric Blake writes:
> On 09/29/2014 10:14 AM, Achim Gratz wrote:
>> Eric Blake (cygwin) writes:
>>> A new release of bash, 4.1.13-6, has been uploaded and will soon reach a
>>> mirror near you; leaving the previous version at 4.12-5.
>> 
>> Just out of curiosity, why is this release version -6 instead of -1?
>
> Because of how upstream bash numbers things.
[...]

Thanks.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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] Updated (experimental): coreutils-8.23-3

[Achim Gratz]

Eric Blake writes:
> Can you give me a simple self-contained script that creates all
> necessary prerequisites before attempting the failing 'cp', to help me
> in trying to reproduce what is going differently here?

I'll see what I can come up with.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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] Updated (experimental): coreutils-8.23-3

[Eric Blake]

On 09/29/2014 03:02 AM, Achim Gratz wrote:
> Eric Blake  byu.net> writes:
>> This build is also the first against the
>> new ACL rules of cygwin1.dll, so there may be some oddities in ls as a
>> result.
> 
> That hunch proved to be correct, but it is cp and not ls that is affected:
> 
>> cp -vr gnuplot.x86_64/dist/gnuplot /mnt/mirror/patch/x86_64/release/
> cp: cannot create directory ‘/mnt/mirror/patch/x86_64/release/gnuplot’: File
> exists
>> getfacl /mnt/mirror/patch/x86_64/release/gnuplot
> # file: /mnt/mirror/patch/x86_64/release/gnuplot
> # owner: share-owner
> # group: Domain Users
> user::---
> group::---
> group:share-adm:rwx
> mask:rwx
> other:---
> default:user::---
> default:group::---
> default:group:share-adm:rwx
> default:mask:rwx
> default:other:---
> 
> The user doing this operation is member of share-adm, but not the
> share-owner.  It seems that cp is deciding that the (existing) directory
> should be newly created, which of course fails.  Reverting to both 8.23-2 or
> 8.15-3 fixes that problem.

Can you give me a simple self-contained script that creates all
necessary prerequisites before attempting the failing 'cp', to help me
in trying to reproduce what is going differently here?

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: bash-4.1.13-6

[Eric Blake]

On 09/29/2014 10:14 AM, Achim Gratz wrote:
> Eric Blake (cygwin) writes:
>> A new release of bash, 4.1.13-6, has been uploaded and will soon reach a
>> mirror near you; leaving the previous version at 4.12-5.
> 
> Just out of curiosity, why is this release version -6 instead of -1?

Because of how upstream bash numbers things.  They only ship a 4.1
tarball, and then 13 official patches that must be applied by the
maintainer on top of that 4.1 tarball.  However, it modifies the micro
version number according to which upstream patches have been applied.
So, this is my sixth time building bash 4.1 for cygwin, and it's just
that bash's micro number bumped from 4.1.12 to 4.1.13 in between my -5
and -6 builds.

When I eventually get bash 4.3 out the door, it will start at 4.3.27-1
(or a higher micro, as there is still a lot of churn in upstream bash to
now patch lower-priority bugs that are no longer Shell Shock attacks
thanks to patch 27, but which are still local crashers).

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] Updated: bash-4.1.13-6

[Achim Gratz]

Eric Blake (cygwin) writes:
> A new release of bash, 4.1.13-6, has been uploaded and will soon reach a
> mirror near you; leaving the previous version at 4.12-5.

Just out of curiosity, why is this release version -6 instead of -1?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

--
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] Updated: bash-4.1.13-6

[Yaakov Selkowitz]

On 2014-09-29 09:18, Buchbinder, Barry (NIH/NIAID) [E] wrote:

Eric Blake (cygwin) sent the following at Saturday, September 27, 2014 2:14 AM

I also turned on the (undocumented) 'bash --wordexp' mode (actually,
that happened in 4.1.12-5, although I failed to mention it at the time),
which allows the C library call wordexp() to now function.


 From a user standpoint, why would one want to use --wordexp?  What is the
effect of turning on this mode?


It's not meant to be used by users.  It exists solely to be used by libc 
(cygwin) as an implementation of wordexp(3).



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: command line smtp client / command line email?

[Joi L. Ellis]

Now that I'm at work, I've done some digging, and here's what I've found...

On my ancient Windows XP box running 32-bit Cygwin, I have a package installed 
that provides /usr/sbin/sendmail.exe as a symlink to /usr/sbin/ssmtp.exe, and a 
shell secript /usr/bin/mailx.sh that is a front-end for it.

I've been using these to send emails from cron, and from my own perl script, 
for several years and have never had any issues.  It even works from a shell 
script thusly:
 
  $ echo "This is the message body" | mailx.sh -s 'this is a test subject' 
jlel...@myemail.com 

And I get the email in my office inbox. (Obviously I've obfuscated my email 
address in the line above as an anti-spam measure.)


--
Joi Owen
System Administrator
Pavlov Media, Inc

-Original Message-
From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of 
Marilo
Sent: Sunday, September 28, 2014 12:21 PM
To: cygwin@cygwin.com
Subject: command line smtp client / command line email?

what are my options for a command line smtp client in cygwin?

I'd want to specify smtp server and from address. I'd like TLS/SSL to be 
supported by the command

sendmail , doesn't look like it exists on cygwin and I know on *nix it shuts 
down any postfix server so I guess it mighttry to shut down any smtp server I 
have running.

heirloom mailx  looks good, but doesn't exist for cygwin.

I can't see anything for sending an email from/in cygwin

--
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] Updated: bash-4.1.13-6

[Buchbinder, Barry (NIH/NIAID) [E]]

Eric Blake (cygwin) sent the following at Saturday, September 27, 2014 2:14 AM
>I also turned on the (undocumented) 'bash --wordexp' mode (actually,
>that happened in 4.1.12-5, although I failed to mention it at the time),
>which allows the C library call wordexp() to now function.

From a user standpoint, why would one want to use --wordexp?  What is the
effect of turning on this mode?

Thanks,

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

Re: gdb 7.8 consistently fails to run executable - error is

[Dominik Straßer]

Hi all,
I've dug into the gdb sources.
The problem is in the cygwin-only part and is not about the PATH
variable but about one single DLL file name.

This path length is *fixed* to 512 characters (SO_NAME_MAX_PATH_SIZE)
for the *realpath* of the DLL.

So there's no way for the user to work around this apart from shortening
the directory or file names.

Best regards

Dominik

Am 25.09.2014 um 13:07 schrieb Dominik Straßer:
> Hi,
> I am running into the same issue.
> My path is stripped down as far as possible:
> $ echo $PATH
> /usr/local/bin:/usr/bin
> 
> But still no cigar.
> 
> $ gdb
> /local/night/fizz_build_Win7_with_icons/libraries/compilelib/unittest/exec/cygwin64/MINGW/normal_mt_so/unittest.exe
> GNU gdb (GDB) 7.8
> Copyright (C) 2014 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-pc-cygwin".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from
> /local/night/fizz_build_Win7_with_icons/libraries/compilelib/unittest/exec/cygwin64/MINGW/normal_mt_so/unittest.exe...done.
> (gdb) r
> Starting program:
> /local/night/fizz_build_Win7_with_icons/libraries/compilelib/unittest/exec/cygwin64/MINGW/normal_mt_so/unittest.exe
> [New Thread 30016.0x7544]
> dll path too long
> 
> strace revealend nothing.
> 
> Unfortunately MinGW's gdb doesn't work for other reasons, so I am back
> to printf :-(
> 
> Regards
> 
> Dominik
> 
> Am 22.08.2014 um 20:32 schrieb DGStevens:
>> Hi Achim-
>>
>> Thanks.  Unfortunately, the change didn't seem to help regarding my issue
>> with GDB.  I don't know if it matters, but I fired up an old computer
>> running XP.  I updated all of the Cygwin software, and tried the same test. 
>> It worked fine on XP, but it seems to fail on Win7, at least for me.
>>
>> FWIW, I tried manually trimming the path to just:
>>
>> $> echo $PATH
>> .:/home/Deans/bin:/usr/local/bin:/usr/bin
>>
>> ...
>>
>> $> cygcheck -s
>>
>> Cygwin Configuration Diagnostics
>> Current System Time: Fri Aug 22 00:02:07 2014
>>
>> Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1
>>
>> Running under WOW64 on AMD64
>>
>> Path:   .
>> C:\cygwin\home\Deans\bin
>> C:\cygwin\usr\local\bin
>> C:\cygwin\bin
>> ...
>>
>>
>>
>>
>> --
>> View this message in context: 
>> http://cygwin.1069669.n5.nabble.com/gdb-7-8-consistently-fails-to-run-executable-error-is-dll-path-too-long-tp110722p110800.html
>> Sent from the Cygwin list mailing list archive at Nabble.com.
>>
>> --
>> 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
>>
> 

-- 
Dominik Strasser   | Phone:  +49 89 99013-436
OneSpin Solutions GmbH | Fax:+49 89 99013-100
Nymphenburgerstr. 20a
80335 Muenchen | dominik.stras...@onespin-solutions.com
Geschaeftsfuehrung: Dr. Raik Brinkmann, Oliver Habeck
Vorsitzender des Beirats: Paul Hill
Sitz: Muenchen; Amtsgericht Muenchen HRB 139464
UstID#: DE 814413215

--
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] Updated (experimental): coreutils-8.23-3

[Achim Gratz]

Eric Blake  byu.net> writes:
> This build is also the first against the
> new ACL rules of cygwin1.dll, so there may be some oddities in ls as a
> result.

That hunch proved to be correct, but it is cp and not ls that is affected:

> cp -vr gnuplot.x86_64/dist/gnuplot /mnt/mirror/patch/x86_64/release/
cp: cannot create directory ‘/mnt/mirror/patch/x86_64/release/gnuplot’: File
exists
> getfacl /mnt/mirror/patch/x86_64/release/gnuplot
# file: /mnt/mirror/patch/x86_64/release/gnuplot
# owner: share-owner
# group: Domain Users
user::---
group::---
group:share-adm:rwx
mask:rwx
other:---
default:user::---
default:group::---
default:group:share-adm:rwx
default:mask:rwx
default:other:---

The user doing this operation is member of share-adm, but not the
share-owner.  It seems that cp is deciding that the (existing) directory
should be newly created, which of course fails.  Reverting to both 8.23-2 or
8.15-3 fixes that problem.


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: How vulnerable are bash users to shellshock bug?

[Achim Gratz]

Andy  gmail.com> writes:
> According to http://www.vox.com/2014/9/25/6843949/the-bash-bug-explained,
> shellshock is exploited when someone submits commands in place of parameter
> data to a server, which then tries to shove the info into an environment
> variable by a bash invocation.  

No, the attack vector is to have a targeted user run bash in an environment
with at least one environment variable having crafted content as to exploit
the bug.  That's quite general and can be used for all sorts of privilege
escalation locally, using it remotely via a service is just the icing on the
cake.


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