Re: [ANN] Cygwin-OpenSSH 8.2.2.2

2020-02-28 Thread Andrey Repin
Greetings, Bill Stewart!

>> No, you must backport all sources to the current and all previous versions
>> and
>> redistribute, or at least make them visible and available on your site,
>> otherwise you are in breach of the licence and must withdraw all
>> distributions
>>

> I have removed the package. (The phrase "no good deed goes unpunished"
> comes to mind.)

> I will put up a separate package later that does not contain any cygwin
> binaries and write a script instead that can download the needed binaries
> and sources using the cygwin setup tool (that the user will have to
> download themselves).

You can download the setup yourself as part of installation process, just make
it clear to the user, what happening, make sure your download process is
sufficiently secure, and include the instructions, how to avoid this in case
the user already have Cygwin environment installed.

> In this way I will be hosting no binaries and will
> not be in violation of any license.


-- 
With best regards,
Andrey Repin
Saturday, February 29, 2020 0:16:46

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: Has rename syntax changed?

2020-02-28 Thread Brian Inglis
On 2020-02-28 11:09, Lee wrote:
> On 2/28/20, Fergus Daly wrote:
>> I am almost certain that the command
>> $ rename "anything" "AnyThing" *.ext
>> would alter the string from lc to uc as shown, anywhere it occurred in any
>> filename in *.ext in the current directory.
>> What I remember as past behaviour now fails, leaving he filename unaltered.
>> (Failure in much the same way as mv would fail if the similar attempt was
>> made.)
>> (Good old DOS command rename (or the abbreviation ren) used to achieve
>> multiple-rename in an easy manner that just eludes bash.)
>> Anyway: has something altered (and quite recently, i think), or am I just
>> mis-remembering the versatility of the command rename?
> 
> Try it with the '-v' option
> 
> $ rename -v anything AnyThing *.ext
> `anything.ext' -> `AnyThing.ext'
> `xxanythingxx.ext' -> `xxAnyThingxx.ext'
> 
> $ rename -v AnyThing anything *.exe
> rename: *.exe: not accessible: No such file or directory
> 
> $ rename -v AnyThing anything *.ext
> `AnyThing.ext' -> `anything.ext'
> `xxAnyThingxx.ext' -> `xxanythingxx.ext'

This will always depend on the file system interface: DOS ignores case changes
as case is not supported, ExFAT/VFAT and everything else preserves case changes,
as do most remote file systems, unless the remote is set up case insensitively
to check the old and new names and ignore case changes (I've been annoyed by
that in the past, normally on proprietary file servers).

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

--
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: Incorrect behavior in TIOCINQ ioctl

2020-02-28 Thread Corinna Vinschen
On Feb 27 22:38, Åke Rehnman wrote:
> Hi,
> 
> I recently ran in to some troubles with the TIOCINQ ioctl. I am wondering if
> the cygwin implementation is correct... It seems if there were any existing
> framing overrun errors etc etc  before calling the TIOCINQ ioctl it is
> returning an error (EINVAL). Reading through linux implmentation of TIOCINQ
> does simply return number of pending chars without any clearing or checking
> for errors.
> 
> I suggest the whole if (ev & CE_FRAME  .. ) is removed.
> 
> Excerpt from fhandler_serial.cc:
> 
> /* ioctl: */
> int
> fhandler_serial::ioctl (unsigned int cmd, void *buf)
> {
> .
> .
>   if (!ClearCommError (get_handle (), &ev, &st))
>     {
>   __seterrno ();
>   res = -1;
>     }
> .
> .
> .
>  case TIOCINQ:
>    if (ev & CE_FRAME || ev & CE_IOE || ev & CE_OVERRUN || ev & CE_RXOVER
>        || ev & CE_RXPARITY)
>      {
>        set_errno (EINVAL);    /* FIXME: Use correct errno */
>        res = -1;
>      }
>  else
>         ipbuf = st.cbInQue;
>  break;

I'm not familiar with serial I/O and the code is pretty stable(*).

- Is it a safe bet that ClearCommError returns valid values in
  st.cbInQue even if one of the error conditions occur?  Maybe the
  right thing to do is to return 0 in certain error cases...?

- Did you actually try if this fixes your problem?  It's pretty
  simple to build the Cygwin DLL
  https://cygwin.com/faq.html#faq.programming.building-cygwin


Corinna

(*) euphemistically for "nobody looked into the code for a long time"


-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature


Re: Has rename syntax changed?

2020-02-28 Thread Lee
On 2/28/20, Fergus Daly wrote:
> I am almost certain that the command
> $ rename "anything" "AnyThing" *.ext
> would alter the string from lc to uc as shown, anywhere it occurred in any
> filename in *.ext in the current directory.
> What I remember as past behaviour now fails, leaving he filename unaltered.
> (Failure in much the same way as mv would fail if the similar attempt was
> made.)
> (Good old DOS command rename (or the abbreviation ren) used to achieve
> multiple-rename in an easy manner that just eludes bash.)
> Anyway: has something altered (and quite recently, i think), or am I just
> mis-remembering the versatility of the command rename?

Try it with the '-v' option

$ rename -v anything AnyThing *.ext
`anything.ext' -> `AnyThing.ext'
`xxanythingxx.ext' -> `xxAnyThingxx.ext'

$ rename -v AnyThing anything *.exe
rename: *.exe: not accessible: No such file or directory

$ rename -v AnyThing anything *.ext
`AnyThing.ext' -> `anything.ext'
`xxAnyThingxx.ext' -> `xxanythingxx.ext'

Lee

--
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: [ANN] Cygwin-OpenSSH 8.2.2.2

2020-02-28 Thread Andrew Schulman via cygwin
> On Thu, Feb 27, 2020 at 3:31 PM Brian Inglis wrote:
> 
> No, you must backport all sources to the current and all previous versions
> > and
> > redistribute, or at least make them visible and available on your site,
> > otherwise you are in breach of the licence and must withdraw all
> > distributions
> >
> 
> I have removed the package. (The phrase "no good deed goes unpunished"
> comes to mind.)

No cheering here about that. Thanks for contributing, and I hope your next
iteration is more successful. Andrew


--
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: 1 [main] bash 3048 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to

2020-02-28 Thread cygwinautoreply
>1 [main] bash 3048 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointe=
>r.  Please report this problem to the public mailing list cygwin@cygwin.com=
>

>Cygwin wurde neu installiert.


https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings

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



1 [main] bash 3048 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report this problem to

2020-02-28 Thread Lampatzer, Rainer
1 [main] bash 3048 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer.  
Please report this problem to the public mailing list 
cygwin@cygwin.com

Cygwin wurde neu installiert.

--
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: OpenSSH: SSHD daemon (as SYSTEM) is partially broken

2020-02-28 Thread Bill Stewart
On Thu, Feb 27, 2020 at 4:10 PM TestUser1 wrote:

So is this expected to work fine in my environment, Windows Server 2016 (OS
> Version 10.0.14393), without the workaround?
>

 I can't reproduce on Windows Server 8.1/Server 2012 R2 or later.

But you can certainly try the workaround.

Bill

--
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: [ANN] Cygwin-OpenSSH 8.2.2.2

2020-02-28 Thread Bill Stewart
On Thu, Feb 27, 2020 at 3:31 PM Brian Inglis wrote:

No, you must backport all sources to the current and all previous versions
> and
> redistribute, or at least make them visible and available on your site,
> otherwise you are in breach of the licence and must withdraw all
> distributions
>

I have removed the package. (The phrase "no good deed goes unpunished"
comes to mind.)

I will put up a separate package later that does not contain any cygwin
binaries and write a script instead that can download the needed binaries
and sources using the cygwin setup tool (that the user will have to
download themselves). In this way I will be hosting no binaries and will
not be in violation of any license.

Bill

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



Has rename syntax changed?

2020-02-28 Thread Fergus Daly
I am almost certain that the command
$ rename "anything" "AnyThing" *.ext
would alter the string from lc to uc as shown, anywhere it occurred in any 
filename in *.ext in the current directory.
What I remember as past behaviour now fails, leaving he filename unaltered.
(Failure in much the same way as mv would fail if the similar attempt was made.)
(Good old DOS command rename (or the abbreviation ren) used to achieve 
multiple-rename in an easy manner that just eludes bash.)
Anyway: has something altered (and quite recently, i think), or am I just 
mis-remembering the versatility of the command rename?
Fergus  

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