Good answers, all. Thanks to everyone for contributing. For anyone who wants a golfed "cat" replacement, command line arguments can give you shorter code:
mydir$ perl6 -e '.say for lines' ab_cd.txt a b c d mydir$ perl6 -ne '.say' ab_cd.txt a b c d mydir$ # below two single quotes as empty arg: mydir$ perl6 -pe '' ab_cd.txt a b c d mydir$ Finally, a question about the 'get' docs, which use 'while' as an example for the (IO::CatHandle) 'get' method. The docs say "(IO::CatHandle) method get: Returns a single line of input from the handle... . Returns Nil when there is no more input. ... ." And, "(IO::Handle) routine get: Reads a single line of input from the handle... . Returns Nil, if no more input is available... ." See: https://docs.raku.org/routine/get Should a different example other than "while/get" be used on the docs page? Or should some of the comments Yary made regarding "while/get" be incorporated into the docs--so programmers can be warned about truncating their output on blank lines with "while/get"? Yary, from Jan. 18th: " 'while' ...will stop when it encounters a false line--typically an empty line or '0' ". Best Regards, Bill. On Mon, Jan 20, 2020 at 4:13 PM Trey Harris <t...@lopsa.org> wrote: > > On Mon, Jan 20, 2020 at 19:03 Trey Harris <t...@lopsa.org> wrote: >> >> On Mon, Jan 20, 2020 at 02:59 William Michels via perl6-users >> <perl6-us...@perl.org> wrote: >>> >>> Hi Yary (and Todd), >>> >>> Thank you both for your responses. Yary, the problem seems to be with >>> "get". I can change 'while' to 'for' below, but using 'get' raku/perl6 >>> actually returns fewer lines with "for" than it did with "while": >> >> >> If you want to do line-oriented input, use `.lines` with `for`; it returns >> something `for` can iterate over. > > > Sorry, in a setting where a handle isn’t the context, I meant `lines`, not > `.lines`, though I was referring _to_ a thing called `.lines`, the multi > method. I don’t think we’ve all yet agreed on how multis that can be called > as plain routines should be referred to in umbrella term. `.lines` is more > “correct”, but it’s less likely to actually work without understanding more, > which is a strange conundrum for documentation. > > Trey
