[Haskell-cafe] Read a single char
Maurício
How can I read a single character from standard output? I would like
the user to press a single key and the reading function return
imediately after that key is pressed.
Thanks,
Maurício
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Donald Bruce Stewart
> Hi,
>
> How can I read a single character from standard output? I would like
> the user to press a single key and the reading function return
> imediately after that key is pressed.
so you want a function of type:
IO Char
asking Hoogle (http://haskell.org/hoogle) we get:
Prelude. getChar :: IO Char
IO. hGetChar :: Handle -> IO Char
-- Don
Maurício
> briqueabraque:
>> Hi,
>>
>> How can I read a single character from standard output? I would like
>> the user to press a single key and the reading function return
>> imediately after that key is pressed.
>
> so you want a function of type:
> IO Char
>
> asking Hoogle (http://haskell.org/hoogle) we get:
> Prelude. getChar :: IO Char
> IO. hGetChar :: Handle -> IO Char
>
> -- Don
getChar doesn't return until I press Enter. I need something that
returns immediately after I press any key.
Thanks,
Maurício
Neil Mitchell
> getChar doesn't return until I press Enter. I need something that
> returns immediately after I press any key.
It's a problem with buffering:
http://haskell.org/hoogle/?q=buffering
suggests:
hSetBuffering stdin NoBuffering
Thanks
Neil
Brian Smith
>
> Hi
>
> > getChar doesn't return until I press Enter. I need something that
> > returns immediately after I press any key.
>
> It's a problem with buffering:
>
This usually doesn't work on Windows:
GHC 6.4.2 and 6.6: requires <enter>
Hugs (console) Sept. 2006: requires <enter>
WinHugs (GUI) Sept. 2006: works as expected
But it seems to work on Linux:
GHC 6.4.1 on Ubuntu 6.06: works as expected
GHC 6.6 on Ubuntu 6.06: works as expected
I am really interested in hearing of a solution that works on all platforms.
> import IO
> main = do
> hSetBuffering stdin NoBuffering
> hGetChar stdin
Regards,
Brian
Maurício
>
> Hi
>
> > getChar doesn't return until I press Enter. I need something that
> > returns immediately after I press any key.
>
> It's a problem with buffering:
>
> hSetBuffering stdin NoBuffering
>
>
> This usually doesn't work on Windows:
>
> GHC 6.4.2 and 6.6: requires <enter>
> Hugs (console) Sept. 2006: requires <enter>
> WinHugs (GUI) Sept. 2006: works as expected
>
> But it seems to work on Linux:
> GHC 6.4.1 on Ubuntu 6.06: works as expected
> GHC 6.6 on Ubuntu 6.06: works as expected
>
> I am really interested in hearing of a solution that works on all
> platforms.
>
Does 'readKey', from System.Console.Readline, works on Windows? It
works on Linux with the buffering advice applied.
Maurício
Dimitri Timofeev
Sorry if it is a bit off-topic in this thread.
How can I input EOF symbol in WinHugs? Ctrl-Z and Ctrl-D don't work for me,
so I can't use getContents function. Maybe there is a piece of documentation
that I should read?
Thanks!
--
Dimitri
Neil Mitchell
> How can I input EOF symbol in WinHugs?
No possible way. If you could type the NUL character that might
possibly work, but even then 1) you can't, 2) it might not.
Do you have a particular need for typing the "end of getContents" in
WinHugs? If so, I can open a bug and might be able to fix it for the
next release.
Dimitri Timofeev
>
> > How can I input EOF symbol in WinHugs?
>
> No possible way. If you could type the NUL character that might
> possibly work, but even then 1) you can't, 2) it might not.
>
> Do you have a particular need for typing the "end of getContents" in
> WinHugs? If so, I can open a bug and might be able to fix it for the
> next release.
Thank you!
Surely I can get along without getContents in WinHugs: last time I thought
about
it I just wanted to show getContents function to my students (and using
hGetContents
on a file handle seems to be better example). Another function that
could be useful when teaching IO is 'interact', and it seems that it's also
impossible to use it without typing EOF (am I right?).
So it would be nice to have a way to type EOF in WinHugs, but surely it's a
feature one can live without.
And thank you for WinHugs, it is really useful!
--
Dimitri
John Meacham
does F6 work? it used to back with DOS something or another.
John
--
John Meacham - ⑆repetae.net⑆john⑈
Dimitri Timofeev
>
>
> does F6 work? it used to back with DOS something or another.
>
It works in console Hugs, as well as Ctrl-Z, but does not work in WinHugs.
--
Dimitri
Neil Mitchell
> Surely I can get along without getContents in WinHugs: last time I thought
> about
> it I just wanted to show getContents function to my students (and using
> hGetContents
> on a file handle seems to be better example). Another function that
> could be useful when teaching IO is 'interact', and it seems that it's also
> impossible to use it without typing EOF (am I right?).
You can use interact, you just have to hit the stop button to break
out of it. Interestingly Ctrl+C is captured by interact, as is
Ctrl+Z/Ctrl+D, so fixing it up to return -1 in these cases should be
pretty easy - i'll try and get that done tomorrow.
> And thank you for WinHugs, it is really useful!
Thank you :) - its nice to know that it is being used.
Hans van Thiel
> I have a similar question. When I use getChar with Hugs the
newline
> (caused by pressing 'Enter') seems to be carried over into
the next
> call of main, where it is treated as a single input
character.
> The workaround is getLine and head, but it would be nice to
drop the
> newline right away. I suppose the solution offered here:
>>that is the correct behavior, input is never discarded, it is
just >>saved
>>up until you press enter for the first time. if you type
>>foo<enter>,
>>your next four getChars will get 'f' 'o' 'o' and '\n'. it is
not >>haskell
>>that is treating enter as specially, it is your terminal,
getChar >>just returns exactly what was passed to it.
Yes, but the problem is with two subsequent runs of main. I'd
have thought the buffer would flush automatically and the second
run would start with an empty buffer. Now I enter 'b', then
press 'Enter' and it works as expected. Then I 'main' again, and
it terminates right away with a blank line. If I enter 'a', 'b'
and then Enter, the second run takes the second character.
If I'm not doing anything wrong (always a possibility :-), then
it seems more like a (small) bug in Hugs, as Neil suggested.
I'll have to check what chgi does. Regards,
Hans
Ross Paterson
> Yes, but the problem is with two subsequent runs of main. I'd
> have thought the buffer would flush automatically and the second
> run would start with an empty buffer. Now I enter 'b', then
> press 'Enter' and it works as expected. Then I 'main' again, and
> it terminates right away with a blank line.
That is normal Unix behaviour. Try the same input with
head -1c | od -c; head -1c | od -c
The terminal buffer is only discarded if a program changes the terminal
mode. Hugs and ghci do (because they use readline), but runhugs doesn't.
Neil Mitchell
> > Do you have a particular need for typing the "end of getContents" in
> > WinHugs? If so, I can open a bug and might be able to fix it for the
> > next release.
>
> Thank you!
Fixed in the CVS version, the next release will allow Ctrl+Z or Ctrl+D
to terminate an input stream. There were also a few additional fixes
around the interact code that I made.
If you want to use these fixes before the next release:
http://haskell.org/hoogle/other/winhugs-interact-fixes-2006-oct-25.zip
Extract winhugs.exe and replace the existing winhugs.exe in a Sep 2006
installation.
Dimitri Timofeev
It works very well, thank you!
On 10/25/06, Neil Mitchell <ndmit...@gmail.com> wrote:
>
>
> Fixed in the CVS version, the next release will allow Ctrl+Z or Ctrl+D
> to terminate an input stream. There were also a few additional fixes
> around the interact code that I made.
>
> If you want to use these fixes before the next release:
>
> http://haskell.org/hoogle/other/winhugs-interact-fixes-2006-oct-25.zip
>
> Extract winhugs.exe and replace the existing winhugs.exe in a Sep 2006
> installation.
>
--
Dimitri