Re: [go-nuts] fmt Scanln skipping 1st character of new word

[Jesse McNelis]

On Fri, Jun 29, 2012 at 7:28 PM, <sirie...@gmail.com> wrote:
>       if ierr == nil || ierr.Error() == "unexpected newline"{
>         break
>       }else if ierr.Error() =="Scan: expected newline"{
>         line+=" "
>       }

You're not checking the error.
"If there is no error then break" is probably not what you want.




--
=====================
http://jessta.id.au

[peterGo]

siriele,

Scanning

Note: Fscan etc. can read one character (rune) past the input they
return, which means that a loop calling a scan routine may skip some
of the input. This is usually a problem only when there is no space
between input values. If the reader provided to Fscan implements
ReadRune, that method will be used to read characters. If the reader
also implements UnreadRune, that method will be used to save the
character and successive calls will not lose data. To attach ReadRune
and UnreadRune methods to a reader without that capability, use
bufio.NewReader.

http://golang.org/pkg/fmt/

Peter

On Jun 29, 5:28 am, siriele...@gmail.com wrote:
> My question here is why is scanln skipping the 1st character after the
> first word in the scan results? for me this isnt terribly important but it
> is some what troubling because i do not know if I am using this library
> wrong or if this is a bug, I have out put attched...dont worry about the
> double printing that is done on purpose. I have the output attached...what
> i type is what comes before the ">" and what gets scanned in, and printed
> twice, is the result of reading in that "in" variable....Am i doing this
> wrong and/or is that a big....its like 430 am and my brain is shitting
> down...any help/ insight would be greatly appreciated. I dont think i have
> upgraded this go to the latest 1.02 btw..could that be it?
>     line:=" "
>     for{
>        var in string
>       _,ierr := fmt.Scanln(&in)
>       fmt.Print(in," ")
>       line += in

>       if ierr == nil || ierr.Error() == "unexpected newline"{
>         break
>       }else if ierr.Error() =="Scan: expected newline"{
>         line+=" "
>       }
>     }
>

> outputs>ok
>
> ok  ok :  1
> [ 2 ]>hello man
>
> hello an  hello an :  2
> [ 3737, 67 ]>what is going on here
>
> what s oing n ere  what s oing n ere :  5
> [ 497, 2, 2, 2 ]
>
>
>
> here is my environment info:
>
> siriele@siriele-MS-7681:~/Documents/PassingThoughts/wordsets$ go version
> go version go1
> siriele@siriele-MS-7681:~/Documents/PassingThoughts/wordsets$ go env
> GOROOT="/usr/lib/go"
> GOBIN=""
> GOARCH="amd64"
> GOCHAR="6"
> GOOS="linux"
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
> GOGCCFLAGS="-g -O2 -fPIC -m64 -pthread"
> CGO_ENABLED="1"
> siriele@siriele-MS-7681:~/Documents/PassingThoughts/wordsets$

[Sonia Keys]

I think the short answer is that if you need to read a variable number of words on a line, you don't want to use Scanln.  Instead, try bufio.ReadString to get the whole line at once, then split it into words with strings.Fields.

The problem with handling the "expected newline" error is that yes, Scanln loses a byte (a rune, really).  Is it a bug?  Well it might be nice if it didn't lose the rune, but I'm not sure it's a bug.  When a function returns an error, it's not safe to assume much other behavior of the function.  Here Scanln is complaining that you asked it to parse a single string followed by a newline and it found something else.  It might not be fair to expect Scanln to do anything in particular (such as unread the non-newline) that it wasn't expecting to have to do.