Re: bc version has issue with \r when run from cmd

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

On 2016-10-24 17:43, L. A. Walsh wrote:
> Andrew Schulman wrote:
>>> Does whoever made the windows port e.g. for the gow one or for the
>>> cygwin one, make their windows ports open source, and  if so, then
>>> does anybody have a link to those?
>>
>> The Cygwin bc package uses the bc 1.06.95 source that I linked to, plus some
>> patches. You can download them all by checking the "Src" box for bc in setup,
>> then looking in /usr/src/bc-1.06.95-2.src/.
>>
>> I doubt that anyone here knows about the Gow bc package.
> ---
>     I was going to ask: what is 'gow'?
>     It seems like it is a program compiled to run
> in the windows subsystem?  If that's the case, they likely
> created a version of 'bc' to run under the windows subsystem.

Github import of some GNU utilities 2006 sources:
https://github.com/bmatzelle/gow/releases
a few updated as recently as early 2014.

>     As may be obvious now, you need to use a command
> shell that is compatible with whatever subsystem you compile
> 'bc' under.
>     What line ending 'bc' uses is dependent on what
> subsystem it was compiled for.  The one in cygwin is designed
> for use in cygwin and apparently the one included with 'gow'
> (whatever that is), is compiled for use from windows.  "bc",
> and most utilities ported from *nix or open-source systems,
> don't care and don't look at line endings -- they expect
> "\n" to be the "end-of-line" indicator.  On *unix* and *mac*
> systems it is 1 character long, but on windows, it's 2 characters
> (<CR>+<LF>).  The utilities would get alot more confused if they
> had to accommodate both, so in general they only look at "\n" and
> rely on however they were built to indicate what that translates
> to in the surrounding environment.

The problem here, as with most Cygwin utilities and cmd, is that
utilities work fine interactively or with command line arguments,
but when cmd does redirection or piping, it gets to open the files,
and Cygwin does not know how the content is going to be used,
so just passes the data along from the source or to the sink.

To improve things for the cmd shell environment, utilities dealing
with text from stdin or to stdout and stderr, would have to freopen
stdin with mode "r" and stdout and stderr with mode "a" to tell
Cygwin to treat the content appropriately as text.

Ths may solve some input issues under cmd, but may cause others
under either cmd or bash, and may only affect output to files on
Cygwin text mounts, if that still outputs carriage returns before
newlines.

Cygwin interoperability with Windows is pretty extensive and DTRT
when it has a hope of figuring out what you're trying to do: in
some cases you *have* to use a decent shell to give it a chance.

For consistent results, you sometimes need to run commands or
scripts using "bash -c command", "bash script", or bash under
mintty.
And use editors that default to Unix line endings, and those and
other GUIs that are somewhat agnostic about paths, slash
directions, and other Windows idiosyncra^H^H^H^H^H^Hcies ;^>

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