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

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

[dapiot holmp]

>From: "L. A. Walsh" <cygwin at tlinx dot org>
>Date: Sat, 22 Oct 2016 15:52:42 -0700

To L.A. Walsh.

I understand all that but what i'm saying is that version 1.06  (not
1.06.95, which cygwin is using, but 1.06, which Gow uses), So, version
1.06   Doesn't have a problem with the fact that cmd sends a \r   So,
if one doesn't want to call it a bug,  then one can call it a lost
feature, useful feature of 1.06 (allowing bc to conveniently also be
used from cmd), and that beneficial flexible feature was lost in
1.06.95

--
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: bc version has issue with \r when run from cmd

[Andrew Schulman]

> >From: "L. A. Walsh" <cygwin at tlinx dot org>
> >Date: Sat, 22 Oct 2016 15:52:42 -0700
> 
> To L.A. Walsh.
> 
> I understand all that but what i'm saying is that version 1.06  (not
> 1.06.95, which cygwin is using, but 1.06, which Gow uses), So, version
> 1.06   Doesn't have a problem with the fact that cmd sends a \r   So,
> if one doesn't want to call it a bug,  then one can call it a lost
> feature, useful feature of 1.06 (allowing bc to conveniently also be
> used from cmd), and that beneficial flexible feature was lost in
> 1.06.95

Hi. I adopted the bc package about a year ago, since fish uses it and I maintain
fish for Cygwin.

I think L.A. is right that because this is an issue of integration between
Cygwin and cmd, it's in the category of a nice-to-have feature. But I get that
it would be useful for you, and maybe for others too.

I haven't looked at the bc source code. It could take some time to find where
the issue is.  A place to start would be to compare the code archives:

http://ftp.gnu.org/gnu/bc/bc-1.06.tar.gz
http://alpha.gnu.org/gnu/bc/bc-1.06.95.tar.bz2

If you were to localize the problem in the source code and even propose a patch,
that would make it a lot more likely to get the problem fixed. Heck, you might
even get a gold star. I maintain the gold star page too :)

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: bc version has issue with \r when run from cmd

[Duncan Roe]

On Sun, Oct 23, 2016 at 06:19:31PM -0400, Andrew Schulman wrote:
> > >From: "L. A. Walsh" <cygwin at tlinx dot org>
> > >Date: Sat, 22 Oct 2016 15:52:42 -0700
> >
> > To L.A. Walsh.
> >
> > I understand all that but what i'm saying is that version 1.06  (not
> > 1.06.95, which cygwin is using, but 1.06, which Gow uses), So, version
> > 1.06   Doesn't have a problem with the fact that cmd sends a \r   So,
> > if one doesn't want to call it a bug,  then one can call it a lost
> > feature, useful feature of 1.06 (allowing bc to conveniently also be
> > used from cmd), and that beneficial flexible feature was lost in
> > 1.06.95
>
> Hi. I adopted the bc package about a year ago, since fish uses it and I maintain
> fish for Cygwin.
>
> I think L.A. is right that because this is an issue of integration between
> Cygwin and cmd, it's in the category of a nice-to-have feature. But I get that
> it would be useful for you, and maybe for others too.
>
> I haven't looked at the bc source code. It could take some time to find where
> the issue is.  A place to start would be to compare the code archives:
>
> http://ftp.gnu.org/gnu/bc/bc-1.06.tar.gz
> http://alpha.gnu.org/gnu/bc/bc-1.06.95.tar.bz2
>
> If you were to localize the problem in the source code and even propose a patch,
> that would make it a lot more likely to get the problem fixed. Heck, you might
> even get a gold star. I maintain the gold star page too :)
>
> Andrew
>
Hi Andrew,

I don't think it's a change to bc. I built and tried bc 1.06 under Linux and it
behaves the same (1.06.95 was released about 10 years ago BTW):

  21:44:51$ ./bc --version
  bc 1.06
  21:53:24$ echo -e "scale=10; 4*a(1)\r"|./bc -l
  (standard_in) 1: illegal character: ^M
  21:59:04$ echo -e "scale=10; 4*a(1)"|./bc -l
  3.1415926532
  21:59:29$

On debugging ./bc, I found this:

  Breakpoint 2, yyparse () at /usr/gnu/share/bison.simple:254
  254     /usr/gnu/share/bison.simple: No such file or directory.
  (gdb) fin
  Run till exit from #0  yyparse () at /usr/gnu/share/bison.simple:254
  (standard_in) 1: illegal character: ^M
  main (argc=1, argv=0xbfffeb34) at main.c:262
  262       if (compile_only)
  Value returned is $1 = 0

So it would seem that the new error is a consequence of some update to flex or
bison in the last 10 years. Does Gow have a patched flex or bison? Or maybe
their bc build is just very old?

Cheers ...  Duncan.

--
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: bc version has issue with \r when run from cmd

[dapiot holmp]

I understand (from a helpful email to me), that the issue/difference
is apparently between ports of bc(whoever made the ports), rather than
the bc version..

I see from andrew,  links to the linux versions of bc on which the
windows ports are based on.

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?

Thanks

--
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: bc version has issue with \r when run from cmd

[Andrew Schulman]

> I understand (from a helpful email to me), that the issue/difference
> is apparently between ports of bc(whoever made the ports), rather than
> the bc version..
> 
> I see from andrew,  links to the linux versions of bc on which the
> windows ports are based on.
> 
> 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.

Good luck.
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: bc version has issue with \r when run from cmd

[L. A. Walsh]

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.

	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.

-l



--
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: bc version has issue with \r when run from cmd

[Brian Inglis]

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

bc version has issue with \r when run from cmd

[dapiot holmp]

the version of bc that comes with cygwin, is bc 1.06.95   it works
fine from within the cygwin environment, but from cmd it doesn't
process \r

C:\cygwin\bin>echo 5+4|.\bc
(standard_in) 1: illegal character: ^M

C:\cygwin\bin>

C:\cygwin\bin>echo 5+4|tr -d '\r'|.\bc
9

C:\cygwin\bin>


Whereas I notice that Gow uses 1.06

And that does work with \r in cmd

C:\Program Files (x86)\Gow\bin>.\bc -v
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 F

C:\Program Files (x86)\Gow\bin>

And  it works fine with \r

C:\Program Files (x86)\Gow\bin>echo 5+4|.\bc
9

C:\Program Files (x86)\Gow\bin>

--
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: bc version has issue with \r when run from cmd

[L. A. Walsh]

dapiot holmp wrote:
> the version of bc that comes with cygwin, is bc 1.06.95   it works
> fine from within the cygwin environment, but from cmd it doesn't
> process \r
> 
> C:\cygwin\bin>echo 5+4|.\bc
> (standard_in) 1: illegal character: ^M
---
	It's not about "bc" not working with cmd.  The problem
is that cmd is sending a "^M" which doesn't happen when you are
"within the cygwin environment".  I.e.  it's not a bug or problem
in "bc", but the fact that you are using "cmd" which sends those 
extra characters all the time (to all programs receiving pipes).

	If you don't want the "^M", don't mix Windows programs
which send the "<CR>" (Carriage Return or "\r") with *nix programs that
only expect a <LF> (Line Feed; ^J or "\n").

	Does that make sense?

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