On Tuesday, 27 March 2012 at 00:05:51 UTC, Andrei Alexandrescu wrote:
> On 3/26/12 2:52 PM, Tyro[17] wrote:
>> Couldn't the state of stdin be checked upon entrance into readf
>> and reopened if it is already closed?
>
> That won't work.

But this does:

import std.stdio, std.array;

extern(C) // As defined for MAC OS X Lion
{
    immutable TCSANOW = 0;
    immutable NCCS    = 20;
    immutable VEOF    = 0;	/* ICANON */

    int tcgetattr(int fd, termios *termios_p);
    int tcsetattr(int fd, int actions, termios *termios_p);

    alias ulong	tcflag_t;
    alias ubyte	cc_t;
    alias ulong	speed_t;

    struct termios {
        tcflag_t	c_iflag;	/* input flags */
        tcflag_t	c_oflag;	/* output flags */
        tcflag_t	c_cflag;	/* control flags */
        tcflag_t	c_lflag;	/* local flags */
        cc_t		c_cc[NCCS];	/* control chars */
        speed_t		c_ispeed;	/* input speed */
        speed_t		c_ospeed;	/* output speed */
    }
}

void main(string[] args)
{
    termios oldT;
    tcgetattr(0, &oldT);

    auto newT = oldT;
    newT.c_cc[VEOF]  = 3;  // temporary reassignment of EOF indicator.
    tcsetattr(0,TCSANOW,&newT);

    string s1;
    writeln("Enter Ctrl-D terminated string (multiline ok):");

    readf(" %s\x04", &s1);
    tcsetattr(0,TCSANOW,&oldT);

    auto arr = s1.split();
    writeln(arr);

    int data;
    readf(" %s", &data);
    writeln(i);
}

Could that technique be used to implement readf for stdin?

>> Wouldn't that accomplish the desired effect while avoiding
>> the pitfalls of scanf?
>
> I don't think this is a pitfall. Essentially you don't have a definition of what constitutes a chunk of input. Once you get that define, you should be able to express it more or less easily.
>

I'm of the opinion that Ctrl-D defines the boundary of that
chunk of input. We simply have to prevent it from closing
the stream when working with stdin.

> Andrei

On Monday, 26 March 2012 at 21:20:00 UTC, Ali Çehreli wrote:
> On 03/26/2012 02:12 PM, Tyro[17] wrote:
>
> > I don't want to provide an explicit terminator, but instead
> > rely on Ctrl-D/Ctrl-Z to do the job while being able to
> > continue processing read request. As explained by Andrei,
> > this is not possible. But in my mind if the stdin stream
> > can be opened once, it can be opened again. What is the
> > negative effect of testing if it is closed and reopening it
> > on entering readf? Especially since there is a unique
> > implementation of readf to deal with input from stdin.
> >
> > What is wrong with implementing reopen() in File for
> > specific use with stdin and then implementing readf
> > like this:
> >
> > uint readf(A...)(in char[] format, A args)
> > {
> > if(stdin.eof) stdin.reopen();
> > return stdin.readf(format, args);
> > }
> >
> > Andrew
>
> That doesn't fit the way standard input and output streams work. These streams are bound to the application from the environment that has started them. The program itself does not have a way of manipulating how these streams are ended or connected.
>
> Imagine that your program's stdin if piped from the output of another process:
>
>   other | yours
>
> Once 'other' finishes with its output, that's the end of the input of 'yours'. 'yours' cannot communicate to the environment that it would like to continue reading more.

Thanks for that explanation. I am only now understanding the
problem.

> What you are asking for could be achieved only if both the environment and the program agreed that this would be the case.

Not really, we can "borrow" Ctrl-D form the OS until our input is
complete. Please see response to Andrei.

> Maybe I am missing something but that has been standard on many environments.
>
> Ali

On 3/27/12 6:54 AM, Tyro[17] wrote:
> On Tuesday, 27 March 2012 at 00:05:51 UTC, Andrei Alexandrescu wrote:
>> On 3/26/12 2:52 PM, Tyro[17] wrote:
>>> Couldn't the state of stdin be checked upon entrance into readf
>>> and reopened if it is already closed?
>>
>> That won't work.
>
> But this does:
[snip]

Very interesting! But then what if people press Ctrl-C? That would end the input instead of ending the program.

> Could that technique be used to implement readf for stdin?

I don't think we should pursue this path.

>>> Wouldn't that accomplish the desired effect while avoiding
>>> the pitfalls of scanf?
>>
>> I don't think this is a pitfall. Essentially you don't have a
>> definition of what constitutes a chunk of input. Once you get that
>> define, you should be able to express it more or less easily.
>>
>
> I'm of the opinion that Ctrl-D defines the boundary of that
> chunk of input. We simply have to prevent it from closing
> the stream when working with stdin.

You're in a sparse minority at best. Every Unix application out there uses Ctrl-D for end-of-console-input, and your users would be surprised by your exotic use of it.

Why not pick any other character for end of chunk - double newline, Ctrl-S, pretty much anything but Ctrl-D? It's a waste of your time to fight a long-established standard.


Andrei

On Tuesday, 27 March 2012 at 15:14:07 UTC, Andrei Alexandrescu wrote:
> On 3/27/12 6:54 AM, Tyro[17] wrote:
>> On Tuesday, 27 March 2012 at 00:05:51 UTC, Andrei Alexandrescu wrote:
>>> On 3/26/12 2:52 PM, Tyro[17] wrote:
>>>> Couldn't the state of stdin be checked upon entrance into readf
>>>> and reopened if it is already closed?
>>>
>>> That won't work.
>>
>> But this does:
> [snip]
>
> Very interesting! But then what if people press Ctrl-C? That would end the input instead of ending the program.
>
>> Could that technique be used to implement readf for stdin?
>
> I don't think we should pursue this path.
>
>>>> Wouldn't that accomplish the desired effect while avoiding
>>>> the pitfalls of scanf?
>>>
>>> I don't think this is a pitfall. Essentially you don't have a
>>> definition of what constitutes a chunk of input. Once you get that
>>> define, you should be able to express it more or less easily.
>>>
>>
>> I'm of the opinion that Ctrl-D defines the boundary of that
>> chunk of input. We simply have to prevent it from closing
>> the stream when working with stdin.
>
> You're in a sparse minority at best. Every Unix application out there uses Ctrl-D for end-of-console-input, and your users would be surprised by your exotic use of it.

Point taken.

> Why not pick any other character for end of chunk - double newline, Ctrl-S, pretty much anything but Ctrl-D? It's a waste of your time to fight a long-established standard.
>

Thanks for the clarification. That's me just not knowing. I've
settled on  Ctrl-X (\x018) because i have access to it without
doing anything special as opposed to Ctrl-S and no operating
system (as far as I know) uses it as a Command line shortcut.
Thanks for keeping the conversation going so I could find a
solution. Now, is it too much it the standard terminator
for string input from stdin?

>
> Andrei

Andrew

On Tuesday, 27 March 2012 at 15:14:07 UTC, Andrei Alexandrescu
wrote:
> On 3/27/12 6:54 AM, Tyro[17] wrote:
>> On Tuesday, 27 March 2012 at 00:05:51 UTC, Andrei Alexandrescu wrote:
>>> On 3/26/12 2:52 PM, Tyro[17] wrote:
>>>> Couldn't the state of stdin be checked upon entrance into readf
>>>> and reopened if it is already closed?
>>>
>>> That won't work.
>>
>> But this does:
> [snip]
>
> Very interesting! But then what if people press Ctrl-C? That would end the input instead of ending the program.
>
>> Could that technique be used to implement readf for stdin?
>
> I don't think we should pursue this path.
>
>>>> Wouldn't that accomplish the desired effect while avoiding
>>>> the pitfalls of scanf?
>>>
>>> I don't think this is a pitfall. Essentially you don't have a
>>> definition of what constitutes a chunk of input. Once you get that
>>> define, you should be able to express it more or less easily.
>>>
>>
>> I'm of the opinion that Ctrl-D defines the boundary of that
>> chunk of input. We simply have to prevent it from closing
>> the stream when working with stdin.
>
> You're in a sparse minority at best. Every Unix application out there uses Ctrl-D for end-of-console-input, and your users would be surprised by your exotic use of it.
>
> Why not pick any other character for end of chunk - double newline, Ctrl-S, pretty much anything but Ctrl-D? It's a waste of your time to fight a long-established standard.
>
>
> Andrei

GDB handles Ctrl-D differently. It doesn't close the input on the
first one, it waits for the second one and then exits. After the
first one it acts like you typed 'quit', which asks you if you
really want to quit when there's a program still running.

On Tue, Mar 27, 2012 at 08:56:56PM +0200, Matt Peterson wrote:
> On Tuesday, 27 March 2012 at 15:14:07 UTC, Andrei Alexandrescu wrote:
[...]
> >You're in a sparse minority at best. Every Unix application out there uses Ctrl-D for end-of-console-input, and your users would be surprised by your exotic use of it.
> >
> >Why not pick any other character for end of chunk - double newline, Ctrl-S, pretty much anything but Ctrl-D? It's a waste of your time to fight a long-established standard.
[...]
> 
> GDB handles Ctrl-D differently. It doesn't close the input on the first one, it waits for the second one and then exits. After the first one it acts like you typed 'quit', which asks you if you really want to quit when there's a program still running.

That's because gdb uses libreadline (or something along those lines) with cbreak, so it can intercept control characters without them getting interpreted by the terminal. This requires manual control of terminal functions, which is something outside the scope of readf(). (You'd be better off writing your own terminal handling from scratch, if that's what you want.)


T

-- 
This is a tpyo.

On Tuesday, 27 March 2012 at 19:05:19 UTC, H. S. Teoh wrote:
> On Tue, Mar 27, 2012 at 08:56:56PM +0200, Matt Peterson wrote:
>> On Tuesday, 27 March 2012 at 15:14:07 UTC, Andrei Alexandrescu
>> wrote:
> [...]
>> >You're in a sparse minority at best. Every Unix application out there
>> >uses Ctrl-D for end-of-console-input, and your users would be
>> >surprised by your exotic use of it.
>> >
>> >Why not pick any other character for end of chunk - double newline,
>> >Ctrl-S, pretty much anything but Ctrl-D? It's a waste of your time to
>> >fight a long-established standard.
> [...]
>> 
>> GDB handles Ctrl-D differently. It doesn't close the input on the
>> first one, it waits for the second one and then exits. After the first
>> one it acts like you typed 'quit', which asks you if you really want
>> to quit when there's a program still running.
>
> That's because gdb uses libreadline (or something along those lines)
> with cbreak, so it can intercept control characters without them getting
> interpreted by the terminal. This requires manual control of terminal
> functions, which is something outside the scope of readf(). (You'd be
> better off writing your own terminal handling from scratch, if that's
> what you want.)
>
>
> T

Ah, nice to know. Thanks.

On 3/27/12 12:56 PM, Matt Peterson wrote:
> GDB handles Ctrl-D differently. It doesn't close the input on the
> first one, it waits for the second one and then exits. After the
> first one it acts like you typed 'quit', which asks you if you
> really want to quit when there's a program still running.

A variety of other programs handle Ctrl-D differently (emacs, vi, etc). They aren't simple console input programs.

Andrei