Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #99315 > unrolled thread

Line read from csv file with fgets has two characters before the terminating one

Back to article view | Back to comp.lang.c

Contents

  Line read from csv file with fgets has two characters before the terminating one Alla _ <modelling.data@gmail.com> - 2016-12-14 00:04 -0800
    Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-14 11:10 +0000
      Re: Line read from csv file with fgets has two characters before the terminating one Alla _ <modelling.data@gmail.com> - 2016-12-14 23:50 -0800
        Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 08:52 +0000
          Re: Line read from csv file with fgets has two characters before the terminating one Alla _ <modelling.data@gmail.com> - 2016-12-15 00:58 -0800
            Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 09:09 +0000
              Re: Line read from csv file with fgets has two characters before the terminating one Alla _ <modelling.data@gmail.com> - 2016-12-15 04:23 -0800
                Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 12:50 +0000
                  Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-15 14:14 +0000
                    Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 14:42 +0000
                    Re: Line read from csv file with fgets has two characters before the terminating one Keith Thompson <kst-u@mib.org> - 2016-12-15 09:49 -0800
                      Re: Line read from csv file with fgets has two characters before the terminating one gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-15 17:58 +0000
                      Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-15 18:22 +0000
                        Re: Line read from csv file with fgets has two characters before the terminating one Keith Thompson <kst-u@mib.org> - 2016-12-15 11:51 -0800
                          Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-15 20:35 +0000
                            Re: Line read from csv file with fgets has two characters before the terminating one Keith Thompson <kst-u@mib.org> - 2016-12-15 12:58 -0800
                            Re: Line read from csv file with fgets has two characters before the terminating one Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 13:11 -0800
                    Re: Line read from csv file with fgets has two characters before the terminating one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 02:14 +0000
                      Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-16 11:25 +0000
                        Re: Line read from csv file with fgets has two characters before the terminating one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-16 16:41 +0000
                          Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-16 22:08 +0000
                            Re: Line read from csv file with fgets has two characters before the terminating one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 02:48 +0000
                              Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-17 11:54 +0000
                                Re: Line read from csv file with fgets has two characters before the terminating one Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 15:33 +0000
                              Re: Line read from csv file with fgets has two characters before the terminating one supercat@casperkitty.com - 2016-12-17 08:27 -0800
                                Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-17 17:25 +0000
                                  Re: Line read from csv file with fgets has two characters before the terminating one Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-17 09:53 -0800
                                    Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-17 18:21 +0000
                                  Re: Line read from csv file with fgets has two characters before the terminating one supercat@casperkitty.com - 2016-12-17 10:30 -0800
                                    Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-17 22:39 +0000
                                      Re: Line read from csv file with fgets has two characters before the terminating one Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-17 14:51 -0800
                                        Re: Line read from csv file with fgets has two characters before the terminating one BartC <bc@freeuk.com> - 2016-12-17 23:12 +0000
                                        Re: Line read from csv file with fgets has two characters before the terminating one supercat@casperkitty.com - 2016-12-18 08:37 -0800
                                          Re: Line read from csv file with fgets has two characters before the terminating one Keith Thompson <kst-u@mib.org> - 2016-12-18 13:14 -0800
              Re: Line read from csv file with fgets has two characters before the terminating one Geoff <geoff@invalid.invalid> - 2016-12-15 15:03 -0800
                Re: Line read from csv file with fgets has two characters before the terminating one Keith Thompson <kst-u@mib.org> - 2016-12-15 15:29 -0800
                  Re: Line read from csv file with fgets has two characters before the terminating one Geoff <geoff@invalid.invalid> - 2016-12-15 20:48 -0800
                    Re: Line read from csv file with fgets has two characters before the terminating one Keith Thompson <kst-u@mib.org> - 2016-12-15 22:58 -0800
                      OSX line endings (Was: Line read from csv file with fgets has two characters before the terminating one) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-16 10:22 +0000
                        Re: OSX line endings (Was: Line read from csv file with fgets has two characters before the terminating one) Geoff <geoff@invalid.invalid> - 2016-12-16 07:29 -0800
                          Making OSX's boot drive case-sensitve (Was: OSX line endings (Was: Line read from csv file with fgets has two characters before the terminating one)) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-17 10:06 +0000
                            Re: Making OSX's boot drive case-sensitve (Was: OSX line endings (Was: Line read from csv file with fgets has two characters before the terminating one)) Geoff <geoff@invalid.invalid> - 2016-12-17 12:39 -0800
                              Re: Making OSX's boot drive case-sensitve (Was: OSX line endings (Was: Line read from csv file with fgets has two characters before the terminating one)) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-18 13:54 +0000
                                Re: Making OSX's boot drive case-sensitve (Was: OSX line endings (Was: Line read from csv file with fgets has two characters before the terminating one)) Geoff <geoff@invalid.invalid> - 2016-12-18 17:57 -0800
                      Re: Line read from csv file with fgets has two characters before the terminating one Geoff <geoff@invalid.invalid> - 2016-12-16 07:12 -0800
                        Re: Line read from csv file with fgets has two characters before the terminating one Keith Thompson <kst-u@mib.org> - 2016-12-16 12:02 -0800
                Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 23:29 +0000
                Re: Line read from csv file with fgets has two characters before the terminating one Alla _ <modelling.data@gmail.com> - 2016-12-16 02:37 -0800
                  Re: Line read from csv file with fgets has two characters before the terminating one Geoff <geoff@invalid.invalid> - 2016-12-16 07:51 -0800
            Re: Line read from csv file with fgets has two characters before the terminating one Manfred <noname@invalid.add> - 2016-12-15 12:22 +0100
              Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 11:29 +0000
                Re: Line read from csv file with fgets has two characters before the terminating one Melzzzzz <Melzzzzz@zzzzz.com> - 2016-12-15 12:40 +0100
                  Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 12:00 +0000
                    Re: Line read from csv file with fgets has two characters before the terminating one Melzzzzz <mel@zzzzz.com> - 2016-12-15 13:09 +0100
                      Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 12:43 +0000
                    Re: Line read from csv file with fgets has two characters before the terminating one "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-15 09:18 -0500
                      Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 14:49 +0000
                        Re: Line read from csv file with fgets has two characters before the terminating one "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-15 10:34 -0500
                Re: Line read from csv file with fgets has two characters before the terminating one Manfred <noname@invalid.add> - 2016-12-15 16:34 +0100
      Re: Line read from csv file with fgets has two characters before the terminating one Alla _ <modelling.data@gmail.com> - 2016-12-15 00:22 -0800
        Re: Line read from csv file with fgets has two characters before the terminating one Richard Heathfield <rjh@cpax.org.uk> - 2016-12-15 09:04 +0000
    Re: Line read from csv file with fgets has two characters before the terminating one mark.bluemel@gmail.com - 2016-12-14 03:38 -0800

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#99709

On 16/12/2016 16:41, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>> You're trying to merge interactive and file input again.
>
> No, I was just suggesting you avoid an infinite loop.
>
> But doesn't writing the prompt to stdout merge the interactive IO with
> the file IO?  I prefer the output to be separated from the prompts.

How do you separate the two types of output on a console?

>> I tried to
>> use code that was portable.
>
> It's more portable to test for EOF as you can't be sure the system won't
> have a way for the user to accidentally close the input.  Anyway, it was
> only a suggestion.

Testing for EOF would make sense if the user inadvertently redirected 
console input to come from a file. Then if there are more blocks in the 
dumped file than there are newline characters in the file, eventually 
the latter will only return EOF and no more Enters.

But this would be getting a long way from the kind of pause() functions 
I was using last century which waited for the next key press or mouse 
click. It would be going backwards.

Anyway it would be harmless. The user eventually presses Ctrl C or Ctrl 
Break to come out of it. If EOF was checked for, the dumped output would 
just stream past anyway.


>> But they might be able to spot how to do that themselves.
>
> How would you suggest?  I know how to on my Linux system, but it's not
> obvious to beginners, and at least one obvious attempt will provoke the
> infinite loop you don't want to avoid.

You just take out the lines that wait for a response.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99720

BartC <bc@freeuk.com> writes:

> On 16/12/2016 16:41, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> You're trying to merge interactive and file input again.
>>
>> No, I was just suggesting you avoid an infinite loop.
>>
>> But doesn't writing the prompt to stdout merge the interactive IO with
>> the file IO?  I prefer the output to be separated from the prompts.
>
> How do you separate the two types of output on a console?

That's up to the system (and the user), but the program has to do the
ground work by prompting to stderr rather than stdout.

>>> I tried to
>>> use code that was portable.
>>
>> It's more portable to test for EOF as you can't be sure the system won't
>> have a way for the user to accidentally close the input.  Anyway, it was
>> only a suggestion.
>
> Testing for EOF would make sense if the user inadvertently redirected
> console input to come from a file.

Or inadvertently closed the stdin stream.

> Then if there are more blocks in
> the dumped file than there are newline characters in the file,
> eventually the latter will only return EOF and no more Enters.

Yes, and without an EOF check the program will not end.  It's not a
common problem but the fix is so trivial it seems churlish to keep
arguing against using it.

> But this would be getting a long way from the kind of pause()
> functions I was using last century which waited for the next key press
> or mouse click. It would be going backwards.

There's not need to go back -- you can keep using if you like.  But if
you are going to do the pause the way you wrote it, it's better to
include an EOF test.

But the modern way is to write utilities that combine well together.  I
want to chose how to page through a program's output.  I don't wany you
do decide what facilities I get for that.  You don't even try to get the
page size right for my terminal.  My preferred pager is configured to
work as I like, and it has features that should not be duplicated in
every program on my system.

> Anyway it would be harmless. The user eventually presses Ctrl C or
> Ctrl Break to come out of it. If EOF was checked for, the dumped
> output would just stream past anyway.
>
>
>>> But they might be able to spot how to do that themselves.
>>
>> How would you suggest?  I know how to on my Linux system, but it's not
>> obvious to beginners, and at least one obvious attempt will provoke the
>> infinite loop you don't want to avoid.
>
> You just take out the lines that wait for a response.

Ah, this is a utility designed for people who will edit C source code to
alter their tool's behaviour.  I missed that.  That's usually considered
a fragile way to configure utilities.  (I'm joking, it's considered
bonkers!)

I'd edit the source to (a) not prompt, (b) not wait, and (c) not insist
on a file name.  Then I would not need to edit it again because I would
then have a dump utility that inter-works with my other tools in a
useful way.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#99731

On 17/12/2016 02:48, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>> Testing for EOF would make sense if the user inadvertently redirected
>> console input to come from a file.
>
> Or inadvertently closed the stdin stream.

Or inadvertently paused it with Ctrl S. Or inadvertently pressed Ctrl C 
and they have to start again. In this application little can seriously 
go wrong.

>
>> Then if there are more blocks in
>> the dumped file than there are newline characters in the file,
>> eventually the latter will only return EOF and no more Enters.
>
> Yes, and without an EOF check the program will not end.  It's not a
> common problem but the fix is so trivial it seems churlish to keep
> arguing against using it.

I spent much of my career writing interactive graphics applications. I'm 
not going to go back to 1970s style Unix utilities.

>> But this would be getting a long way from the kind of pause()
>> functions I was using last century which waited for the next key press
>> or mouse click. It would be going backwards.
>
> There's not need to go back -- you can keep using if you like.  But if
> you are going to do the pause the way you wrote it, it's better to
> include an EOF test.
>
> But the modern way is to write utilities that combine well together.  I
> want to chose how to page through a program's output.  I don't wany you
> do decide what facilities I get for that.  You don't even try to get the
> page size right for my terminal.

Have you seen the code needed to get the size of a terminal? Which is 
also different across OSes unless you then drag in cross-platform third 
party libraries. You forget this is a compact, self-contained program 
posted as a c.l.c example. And the bigger it is, the more things it will 
have that people won't like.

Anyway it's also important the block size is significant. and I chose a 
power of two: 512 bytes (also a typical sector size), displayed as 32 
rows of 16 bytes. I supposed that could be reduced to 16 rows to 
accommodate screens of 24 rows.

>> You just take out the lines that wait for a response.

> (I'm joking, it's considered
> bonkers!)

Why is it bonkers? It's presented in a few dozen lines of C source in a 
thread about learning C.

> I'd edit the source to (a) not prompt, (b) not wait, and (c) not insist
> on a file name.

So someone is supposed to run it as:

    dump <file

Then anyone who types 'dump' or 'dump file' will see one of those 
mysterious programs that appears to hang. Until they type a few 
tentative keys to see if it's still alive, and they get those echoed. 
Really user-friendly!

And if they do manage 'dump <file', they will get the entire file dumped 
at once until they figure out how to capture or scroll the output, or 
which program they have to pipe it to in order actually see the results.

Apart from which, if they do 'dump <file' on a Windows TXT file, it will 
likely suppress the CR part of CRLF line endings. Then if the output is 
organised into rows, it will get out of step and the offsets will be 
incorrect.

  Then I would not need to edit it again because I would
> then have a dump utility that inter-works with my other tools in a
> useful way.

I can imagine that if you posted such a program here, if wouldn't be a 
dump program at all, or not one of any use, unless it's invoked under 
Unix in a certain way (and presumably with a bunch of options) and in 
conjunction with other utilities.

In that case there wouldn't be any point as you would just run hexdump.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99749

BartC <bc@freeuk.com> writes:

> On 17/12/2016 02:48, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> Testing for EOF would make sense if the user inadvertently redirected
>>> console input to come from a file.
>>
>> Or inadvertently closed the stdin stream.
>
> Or inadvertently paused it with Ctrl S. Or inadvertently pressed Ctrl
> C and they have to start again. In this application little can
> seriously go wrong.

No, I gave another example of why the test you won't add would be
useful.  These are example of other things which you might want to
consider as well, but they are much more complicated to deal with.

What I can't understand is the dogged Resistance to adding a simple test
that clearly reduces the change of a user surprise.

>>> Then if there are more blocks in
>>> the dumped file than there are newline characters in the file,
>>> eventually the latter will only return EOF and no more Enters.
>>
>> Yes, and without an EOF check the program will not end.  It's not a
>> common problem but the fix is so trivial it seems churlish to keep
>> arguing against using it.
>
> I spent much of my career writing interactive graphics
> applications. I'm not going to go back to 1970s style Unix utilities.

What?  This is not an interactive graphics application, nor is it a Unix
style utility (from the 70s or any other decade).  You could make it
into either if you wished, but I was offering a suggestion about the
code you actually wrote.

If you post code, people will comment on it.  If you don't like a
particular comment, just say something like "thanks, but this program
does what I want and I don't want to make any changes to it".

>>> But this would be getting a long way from the kind of pause()
>>> functions I was using last century which waited for the next key press
>>> or mouse click. It would be going backwards.
>>
>> There's not need to go back -- you can keep using if you like.  But if
>> you are going to do the pause the way you wrote it, it's better to
>> include an EOF test.
>>
>> But the modern way is to write utilities that combine well together.  I
>> want to chose how to page through a program's output.  I don't wany you
>> do decide what facilities I get for that.  You don't even try to get the
>> page size right for my terminal.
>
> Have you seen the code needed to get the size of a terminal?

Yes, of course.  That's why I'm not suggesting you do that.

> Which is
> also different across OSes unless you then drag in cross-platform
> third party libraries. You forget this is a compact, self-contained
> program posted as a c.l.c example. And the bigger it is, the more
> things it will have that people won't like.

Exactly.  To my mind, it has just one feature too many -- guessing what
page size the user would like and prompting to display the next page.
I'm sure some people will like the choices you've made, but I prefer a
more flexible utility.

> Anyway it's also important the block size is significant. and I chose
> a power of two: 512 bytes (also a typical sector size), displayed as
> 32 rows of 16 bytes. I supposed that could be reduced to 16 rows to
> accommodate screens of 24 rows.

I have no objection to marking the blocks in some useful way, but
there's no reason that has to be linked to a display size.

>>> You just take out the lines that wait for a response.
>
>> (I'm joking, it's considered
>> bonkers!)
>
> Why is it bonkers? It's presented in a few dozen lines of C source in
> a thread about learning C.

No.  A reader could have taken your posting as being useful hex dump
utility that could already be used to collect the output in a file (for
example so the student can post it here).

We're in agreement.  The program is not so good for that as it stands.

>> I'd edit the source to (a) not prompt, (b) not wait, and (c) not insist
>> on a file name.
>
> So someone is supposed to run it as:
>
>    dump <file
>
> Then anyone who types 'dump' or 'dump file' will see one of those
> mysterious programs that appears to hang.

No, I only said "not insist on a file name".  I would want a file name
to be accepted.  It will, however, just sit there if you type

  dump

(With some programs that insist on a file I can get round it by using
/dev/stdin, but that obviously won't work with a program like yours that
uses stdin already.)

<snip>
> Apart from which, if they do 'dump <file' on a Windows TXT file, it
> will likely suppress the CR part of CRLF line endings.

A dump utility that can read stdin should try to read it in binary mode
but I'm pretty not sure freopen with a NULL file name does not work in
Windows.  So, yes, writing a portable version of the sort of utility
that is common in the Unix word is almost impossible.  Insisting on a
file name gets round that.

Editing the code was your suggestion for customising it, so I was saying
what I'd want.

<snip>
> I can imagine that if you posted such a program here, if wouldn't be a
> dump program at all, or not one of any use, unless it's invoked under
> Unix in a certain way (and presumably with a bunch of options) and in
> conjunction with other utilities.

I'm not sure what the "other utilities" remark is about, but you are
right that I would have posted "Unixy" code without thinking of the
portability.

> In that case there wouldn't be any point as you would just run
> hexdump.

Right.  And I hope that, having posted my Unixy version, you would point
out the trouble with dumping stdin and I would say say "Good point".

One solution (for a program aimed at students) would be to print a
warning (to stderr) that the program is reading from a text stream and
that only "dump file" is reliable.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#99753

On Friday, December 16, 2016 at 8:48:31 PM UTC-6, Ben Bacarisse wrote:
> But the modern way is to write utilities that combine well together.  I
> want to chose how to page through a program's output.  I don't wany you
> do decide what facilities I get for that.  You don't even try to get the
> page size right for my terminal.  My preferred pager is configured to
> work as I like, and it has features that should not be duplicated in
> every program on my system.

It is useful to have a standard means of creating filters, but that does not
imply that user-facing I/O, filters, and disk files should all try to use the
same semantics.  Text-based MS-DOS programs could achieve keyboard and screen
semantics which were more versatile than is possible using only byte-based
interfaces (e.g. in PC-Write, when num-lock was off, the keypad + and - keys
would act as find-next and find-prev, but uses could type + by using shift-
equals, or by using the keypad + when num-lock was on).  Feeding input from
a file to such a program would require a special utiltiy rather than simply
using a < redirect, but such a utility could combine the contents of a file
with live-typed input--something Unix doesn't really handle.

Further, while it would be possible to construct filters using only semantics
of the Standard C Library, that doesn't mean that such semantics are adequate
to do things efficiently.  If one has a huge text file and wants the last
five lines that contain the string "Fred", one could use:

    grep Fred <bigfile | tail -5

but if bigfile had 1,000,000 lines containing that string, such a course of
action would entail scanning all of bigfile, and sending all 1,000,000 of
the matching lines to "tail", which would then ignore it.  If there were
instead a form of filter that processed requests from the output side and
then issued requests for input, and if there were a request to find the
Nth line from the end, then if the author of "grep" wanted to make such
usage efficient it could check whether the input file supported efficient
seeking and, if so, respond to such a request by seeking some distance (e.g. roughly 5000 bytes) from the end, finding the next line break, and then
seeing how many lines from that point to the end contain the required
string.  If less than five, it could then seek to a spot earlier in the
file and repeat until it had found five lines.

The Unix approach works and is simple, but it is also IMHO a victim of its
own success, resulting in stagnation rather than the development of more
efficient patterns.

[toc] | [prev] | [next] | [standalone]

#99757

On 17/12/2016 16:27, supercat@casperkitty.com wrote:
> On Friday, December 16, 2016 at 8:48:31 PM UTC-6, Ben Bacarisse wrote:
>> But the modern way is to write utilities that combine well together.  I
>> want to chose how to page through a program's output.  I don't wany you
>> do decide what facilities I get for that.  You don't even try to get the
>> page size right for my terminal.  My preferred pager is configured to
>> work as I like, and it has features that should not be duplicated in
>> every program on my system.
>
> It is useful to have a standard means of creating filters, but that does not
> imply that user-facing I/O, filters, and disk files should all try to use the
> same semantics.  Text-based MS-DOS programs could achieve keyboard and screen
> semantics which were more versatile than is possible using only byte-based
> interfaces (e.g. in PC-Write, when num-lock was off, the keypad + and - keys
> would act as find-next and find-prev, but uses could type + by using shift-
> equals, or by using the keypad + when num-lock was on).  Feeding input from
> a file to such a program would require a special utiltiy rather than simply
> using a < redirect, but such a utility could combine the contents of a file
> with live-typed input--something Unix doesn't really handle.

Unix doesn't seem to handle the keyboard at all apart from the absolute 
basics.

Even if Home is recognised, for example, then one system might also 
recognise Ctrl-Home (almost universally used to get to the start of a 
block of text or a file), another won't. (And Ctrl-Home might be 
returned as the key-sequence "<esc>[1;5H", so convenient!)

There is no standard way of waiting for a single key. There is no 
standard way to do what I think is called 'non-blocking input' - testing 
whether a key has been pressed without hanging about if it hasn't.

Keys such as Ctrl and Home have been common on keyboards for decades. 
But they might as well not exist as far as Unix is concerned. Unless you 
run a GUI which somehow manages to get around all these limitations.

Windows is much better at this stuff. The API can be fiddly but once 
done you know it will work on any Windows OS.

> The Unix approach works and is simple, but it is also IMHO a victim of its
> own success, resulting in stagnation rather than the development of more
> efficient patterns.

It means a console app has to be crippled to run on Unix. Everything has 
to be reduced to some function lazily operating on a sequence of bytes 
with the output passed to another function. Forget any form of user 
interaction!

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99759

On Saturday, December 17, 2016 at 5:25:36 PM UTC, Bart wrote:
> 
> It means a console app has to be crippled to run on Unix. Everything has 
> to be reduced to some function lazily operating on a sequence of bytes 
> with the output passed to another function. Forget any form of user 
> interaction!
> 
Beginner programs usually run a little dialog with the user.

Enter number of employees
123
Please enter an number between 0 and 10
9
Enter name of employee number 0
Fred Bloggs

etc

It's rare to want to run a program like that for real. However you
do frequently want a reasonably rich set of options on the command
line. 

Another pattern is to use the console window as a raster for a
graphical display, like the game Rogue. You rarely see that these
days, because Ascii artworks are isn't aesthetically very good. 
However it's a good way for programmer who have no art skills 
to get graphics up and running.

[toc] | [prev] | [next] | [standalone]

#99760

On 17/12/2016 17:53, Malcolm McLean wrote:
> On Saturday, December 17, 2016 at 5:25:36 PM UTC, Bart wrote:
>>
>> It means a console app has to be crippled to run on Unix. Everything has
>> to be reduced to some function lazily operating on a sequence of bytes
>> with the output passed to another function. Forget any form of user
>> interaction!
>>
> Beginner programs usually run a little dialog with the user.
>
> Enter number of employees
> 123
> Please enter an number between 0 and 10
> 9
> Enter name of employee number 0
> Fred Bloggs
>
> etc
>
> It's rare to want to run a program like that for real. However you
> do frequently want a reasonably rich set of options on the command
> line.

There are plenty of real programs that do just that:

   > format C:
   Are you sure (Y/N)?

Or:

   > python
   >>> print (2+4)
    6
   >>> etc

Or my IDE which usually sits in a loop waiting for the next line-command 
to be typed to it.

> Another pattern is to use the console window as a raster for a
> graphical display, like the game Rogue. You rarely see that these
> days, because Ascii artworks are isn't aesthetically very good.
> However it's a good way for programmer who have no art skills
> to get graphics up and running.

Another real pattern is to use the console window as an array of 
characters rather than pixels, as in text-based editors, IDEs, file 
managers, text games etc. But they usually demand extra key events 
beyond the bare TTY-style of Unix.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#99761

On Saturday, December 17, 2016 at 11:25:36 AM UTC-6, Bart wrote:
> Even if Home is recognised, for example, then one system might also 
> recognise Ctrl-Home (almost universally used to get to the start of a 
> block of text or a file), another won't. (And Ctrl-Home might be 
> returned as the key-sequence "<esc>[1;5H", so convenient!)
> 
> There is no standard way of waiting for a single key. There is no 
> standard way to do what I think is called 'non-blocking input' - testing 
> whether a key has been pressed without hanging about if it hasn't.

There are some common libraries like "curses" which can accomplish such
things, but the amount of effort required to make such things work can
be rather substantial.  Enough systems support character-at-a-time input
that having a uniform way of saying "Either give me one keystroke from
the console, waiting for up to about N milliseconds, or else report that
such a feature is unsupported" would be more useful than having to use
different code on every system supporting that feature.

[toc] | [prev] | [next] | [standalone]

#99772

On 17/12/2016 18:30, supercat@casperkitty.com wrote:
> On Saturday, December 17, 2016 at 11:25:36 AM UTC-6, Bart wrote:
>> Even if Home is recognised, for example, then one system might also
>> recognise Ctrl-Home (almost universally used to get to the start of a
>> block of text or a file), another won't. (And Ctrl-Home might be
>> returned as the key-sequence "<esc>[1;5H", so convenient!)
>>
>> There is no standard way of waiting for a single key. There is no
>> standard way to do what I think is called 'non-blocking input' - testing
>> whether a key has been pressed without hanging about if it hasn't.
>
> There are some common libraries like "curses" which can accomplish such
> things, but the amount of effort required to make such things work can
> be rather substantial.  Enough systems support character-at-a-time input
> that having a uniform way of saying "Either give me one keystroke from
> the console, waiting for up to about N milliseconds, or else report that
> such a feature is unsupported" would be more useful than having to use
> different code on every system supporting that feature.

I've looked at 'curses' before. Or is it 'ncurses'? Or 'pdcurses'? I 
think it's a bit over the top for what is needed, trying to implement 
its own windowing system.

I need something like: init(), setpos(), getpos(), getkey(), testkey(), 
setattr(), getattr(). But the header file runs to 2000 lines and 
apparently hundreds of functions or macros.

If someone wants to superimpose a window system, then can do that 
themselves (and it will exactly match their requirements). What they 
can't do themselves is getting access to a Ctrl-Home event if the 
terminal driver doesn't support it, or access it in a way that will work 
on any Unix/Linux that has a keyboard attached to it with a Ctrl key and 
a Home key.

You'd think however that this stuff is so fundamental that it would be 
directly available in any OS without having to worry about downloading 
third party libraries for the purpose.

For that matter, why shouldn't C have such functions as standard? 
(Actually I can guess why!)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99773

On Saturday, December 17, 2016 at 10:39:56 PM UTC, Bart wrote:
>
> I need something like: init(), setpos(), getpos(), getkey(), testkey(), 
> setattr(), getattr(). But the header file runs to 2000 lines and 
> apparently hundreds of functions or macros.
> 
Essentially that's curses.
>
> You'd think however that this stuff is so fundamental that it would be 
> directly available in any OS without having to worry about downloading 
> third party libraries for the purpose.
>
curses and conio.h (the Microsoft not quite compatible way of doing
the same thing) are pretty much always available.
> 
> For that matter, why shouldn't C have such functions as standard? 
> (Actually I can guess why!)
> 
Because you can't then hook up a C program to modem and telephone
wire. C stdio is built for a line-oriented world. not a raster
graphics world.

[toc] | [prev] | [next] | [standalone]

#99775

On 17/12/2016 22:51, Malcolm McLean wrote:
> On Saturday, December 17, 2016 at 10:39:56 PM UTC, Bart wrote:
>>
>> I need something like: init(), setpos(), getpos(), getkey(), testkey(),
>> setattr(), getattr(). But the header file runs to 2000 lines and
>> apparently hundreds of functions or macros.
>>
> Essentially that's curses.
>>
>> You'd think however that this stuff is so fundamental that it would be
>> directly available in any OS without having to worry about downloading
>> third party libraries for the purpose.
>>
> curses and conio.h (the Microsoft not quite compatible way of doing
> the same thing) are pretty much always available.

I tried curses and there were complications. It just got in the way with 
its unnecessary API.

conio.h and getch() are OK for simple programs like the dump routine but 
getch() is not up to returning more detailed keyboard info. That 
requires a complicated set of Win32 calls.


>> For that matter, why shouldn't C have such functions as standard?
>> (Actually I can guess why!)
>>
> Because you can't then hook up a C program to modem and telephone
> wire. C stdio is built for a line-oriented world. not a raster
> graphics world.

It's a low level systems language. It should be up for anything. But it 
seems to be inextricably linked to Unix, and Unix apparently hasn't 
found a way to progress beyond serial terminals. Not without taking the 
giant leap into X windows.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#99816

On Saturday, December 17, 2016 at 4:51:59 PM UTC-6, Malcolm McLean wrote:
> Because you can't then hook up a C program to modem and telephone
> wire. C stdio is built for a line-oriented world. not a raster
> graphics world.

The C89 Standard recognized two categories of C implementations--those
which are required to have certain features including input and output
streams, and those which aren't required to have such features.  Given
that there are many features that are common to most, though not all,
of the platforms that are used to run hosted implementations, it would
seem helpful to subdivide the category of hosted implementations into
a couple subcategories--one of which includes such features and one of
which doesn't.

Unfortunately, I think the maintainers of the C Standard would rather
pretend that the world only needs two kinds of C implementations to
satisfy the needs of all programs for which any kind of portability
would be desirable, than recognize that many programs need features
which are present on most but not all platforms.

[toc] | [prev] | [next] | [standalone]

#99842

supercat@casperkitty.com writes:
> On Saturday, December 17, 2016 at 4:51:59 PM UTC-6, Malcolm McLean wrote:
>> Because you can't then hook up a C program to modem and telephone
>> wire. C stdio is built for a line-oriented world. not a raster
>> graphics world.
>
> The C89 Standard recognized two categories of C implementations--those
> which are required to have certain features including input and output
> streams, and those which aren't required to have such features.  Given
> that there are many features that are common to most, though not all,
> of the platforms that are used to run hosted implementations, it would
> seem helpful to subdivide the category of hosted implementations into
> a couple subcategories--one of which includes such features and one of
> which doesn't.
>
> Unfortunately, I think the maintainers of the C Standard would rather
> pretend that the world only needs two kinds of C implementations to
> satisfy the needs of all programs for which any kind of portability
> would be desirable, than recognize that many programs need features
> which are present on most but not all platforms.

I believe the maintainers of the C standard are aware of the existence
of POSIX.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#99581

On Thu, 15 Dec 2016 09:09:19 +0000, Richard Heathfield
<rjh@cpax.org.uk> wrote:

>Excel is by Microsoft. Microsoft wrote Windows, which uses screwy line 
>endings for text files. You don't think Excel might write a screwy text 
>file even on MacOS, just out of sheer habit?

Excel 2016 for Mac outputs 0D-only end of lines in csv files.

[toc] | [prev] | [next] | [standalone]

#99583

Geoff <geoff@invalid.invalid> writes:
> On Thu, 15 Dec 2016 09:09:19 +0000, Richard Heathfield
> <rjh@cpax.org.uk> wrote:
>>Excel is by Microsoft. Microsoft wrote Windows, which uses screwy line 
>>endings for text files. You don't think Excel might write a screwy text 
>>file even on MacOS, just out of sheer habit?
>
> Excel 2016 for Mac outputs 0D-only end of lines in csv files.

Are you sure it's not 0A?

0x0d, or 13, is ASCII CR ('\r'), which was used as the end-of-line
marker by pre-OSX MacOS.  Modern MacOS uses 0x0a, which is ASCII LF.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#99598

On Thu, 15 Dec 2016 15:29:52 -0800, Keith Thompson <kst-u@mib.org>
wrote:

>Geoff <geoff@invalid.invalid> writes:
>> On Thu, 15 Dec 2016 09:09:19 +0000, Richard Heathfield
>> <rjh@cpax.org.uk> wrote:
>>>Excel is by Microsoft. Microsoft wrote Windows, which uses screwy line 
>>>endings for text files. You don't think Excel might write a screwy text 
>>>file even on MacOS, just out of sheer habit?
>>
>> Excel 2016 for Mac outputs 0D-only end of lines in csv files.
>
>Are you sure it's not 0A?
>

Absolutely sure. But there are FOUR different csv format selections in
the Save As... dialog, only one of them outputs a single-byte EOL.

The four selections are:
CSV UTF-8 (Comma delimited) (.csv)
Comma Separated Values (.csv)
Windows Comma Separated (.csv)
MS-DOS Comma Separated (.csv)

Only the first one (CSV UTF-8) uses the 0D ending. All the others use
0D, 0A. This was proven by using hexdump on a sample file.

The CSV UTF-8 format is at the top of the list, under "Common
Formats". The other are listed as "Specialty Formats".

[toc] | [prev] | [next] | [standalone]

#99600

Geoff <geoff@invalid.invalid> writes:
> On Thu, 15 Dec 2016 15:29:52 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
>>Geoff <geoff@invalid.invalid> writes:
>>> On Thu, 15 Dec 2016 09:09:19 +0000, Richard Heathfield
>>> <rjh@cpax.org.uk> wrote:
>>>>Excel is by Microsoft. Microsoft wrote Windows, which uses screwy line 
>>>>endings for text files. You don't think Excel might write a screwy text 
>>>>file even on MacOS, just out of sheer habit?
>>>
>>> Excel 2016 for Mac outputs 0D-only end of lines in csv files.
>>
>>Are you sure it's not 0A?
>
> Absolutely sure. But there are FOUR different csv format selections in
> the Save As... dialog, only one of them outputs a single-byte EOL.
>
> The four selections are:
> CSV UTF-8 (Comma delimited) (.csv)
> Comma Separated Values (.csv)
> Windows Comma Separated (.csv)
> MS-DOS Comma Separated (.csv)
>
> Only the first one (CSV UTF-8) uses the 0D ending. All the others use
> 0D, 0A. This was proven by using hexdump on a sample file.
>
> The CSV UTF-8 format is at the top of the list, under "Common
> Formats". The other are listed as "Specialty Formats".

Which means that a CSV file exported in "CSV-UTF-8" format is not a
text file.  If you try to open it with a text editor, it will likely
appear as one very long line with no line endings at all (unless some
MacOS editors still recognize pre-OSx text files).  It means that
"wc -l filename.csv" won't tell you how many lines are in the file.

That's astonishing.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#99621 — OSX line endings (Was: Line read from csv file with fgets has two characters before the terminating one)

In article <ln4m24l5qs.fsf@kst-u.example.com>,
Keith Thompson  <kst-u@mib.org> was astonished that:
...
>Which means that a CSV file exported in "CSV-UTF-8" format is not a
>text file.  If you try to open it with a text editor, it will likely
>appear as one very long line with no line endings at all (unless some
>MacOS editors still recognize pre-OSx text files).  It means that
>"wc -l filename.csv" won't tell you how many lines are in the file.
>
>That's astonishing.

The default OSX text editor (TextEdit) has no problem with \r-terminated
lines.  So there's really nothing to see here.

OSX is still littered with bits of "Old Mac OS" compatibility things, such
as the non-case-sensitive filesystem.  This, in particular, makes OSX "not
quite Unix".

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/Pedantic

[toc] | [prev] | [next] | [standalone]

#99659 — Re: OSX line endings (Was: Line read from csv file with fgets has two characters before the terminating one)

On Fri, 16 Dec 2016 10:22:28 +0000 (UTC), gazelle@shell.xmission.com
(Kenny McCormack) wrote:

>In article <ln4m24l5qs.fsf@kst-u.example.com>,
>Keith Thompson  <kst-u@mib.org> was astonished that:
>...
>>Which means that a CSV file exported in "CSV-UTF-8" format is not a
>>text file.  If you try to open it with a text editor, it will likely
>>appear as one very long line with no line endings at all (unless some
>>MacOS editors still recognize pre-OSx text files).  It means that
>>"wc -l filename.csv" won't tell you how many lines are in the file.
>>
>>That's astonishing.
>
>The default OSX text editor (TextEdit) has no problem with \r-terminated
>lines.  So there's really nothing to see here.
>

Confirmed. TextEdit handles both variations without trouble. The cat
command, on the other hand, can't handle the 0x0d endings, it
overprints the lines.

>OSX is still littered with bits of "Old Mac OS" compatibility things, such
>as the non-case-sensitive filesystem.  This, in particular, makes OSX "not
>quite Unix".

It's case-insensitive by default but you can enable it.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web