8
\$\begingroup\$

I'm going to post a challenge that requires taking a multiple line string as input. What's the best way to go about this? I don't want any languages to be excluded because they can't take input in a certain way. Should I

  • Let each poster determine how they want to take input? This might lead to unintended exploits.

  • Give input as several strings?

  • A list of strings?

  • Command line arguments?

I'm not sure what makes the most sense.

\$\endgroup\$
  • \$\begingroup\$ If you allow functions, multiline input show be a non-issue. \$\endgroup\$ – Dennis Dec 30 '15 at 22:45
  • 1
    \$\begingroup\$ @Dennis that's what I ended up doing. \$\endgroup\$ – DJMcMayhem Dec 30 '15 at 22:46
7
\$\begingroup\$

Almost all languages can take multiline input.

However, for those that can't, I usually allow an alternative separator to newline (for example, "lines can be separated by either newlines or commas").

\$\endgroup\$
  • \$\begingroup\$ Probably a very basic question, but how is multiline input provided by user? If the user presses "enter", how to distinguish if that "enter" marks a new line or the end of input? What I usually do is to input a blank line (press "enter" twice) to mark the end. But there must be a better way \$\endgroup\$ – Luis Mendo Jan 5 '16 at 4:53
  • \$\begingroup\$ @LuisMendo Why not just read all of STDIN? \$\endgroup\$ – Doorknob Jan 5 '16 at 12:11
  • \$\begingroup\$ I'm thinking about interactive input. Perhaps you mean "command-line" style input? \$\endgroup\$ – Luis Mendo Jan 5 '16 at 12:43
  • \$\begingroup\$ @LuisMendo I'm not sure I follow. Can you give an example? \$\endgroup\$ – Doorknob Jan 5 '16 at 12:59
  • \$\begingroup\$ Assume that the program accepts an arbitrary number of lines as input via keyboard. Input is interactive, meaning you run the program and then it asks for input. You type one line, press "enter"; type a second line, press "enter". How to tell the program (the interpreter) that that line is the last? You need something like a blank line as "end-of-input" mark \$\endgroup\$ – Luis Mendo Jan 5 '16 at 14:23
  • \$\begingroup\$ @LuisMendo Why would you use a blank line when you can just read the entirety of STDIN in your program (and then "terminate" the input with EOF)? \$\endgroup\$ – Doorknob Jan 5 '16 at 21:42
  • \$\begingroup\$ Now it's me who doesn't follow (sorry about my ignorance). How do you produce EOF from the keyboard? \$\endgroup\$ – Luis Mendo Jan 6 '16 at 0:18
  • 1
    \$\begingroup\$ @LuisMendo ^D (on most sane Unix/Linux systems). (No idea if you're on Windows.) \$\endgroup\$ – Doorknob Jan 6 '16 at 0:22
  • \$\begingroup\$ Thanks! I had no idea about that! And yes, I'm on Windows. Here it's Control-Z, apparently \$\endgroup\$ – Luis Mendo Jan 6 '16 at 0:26
4
\$\begingroup\$

All of the things you mention are reasonable options. I'd just allow any of these. At the very least, a linefeed-delimited string and a list-type of strings seem like good options that can hardly be exploited. If there are any characters that can't appear in the lines, you might also allow those as alternative delimiters, to cover languages which have trouble reading multiple lines as well as lack list types.

The phrase I usually use is "you may take input in any convenient list or string format [as long as the data is not pre-processed]". For output, I also add "unambiguous" to "convenient" to ensure that people use proper delimiters. So far I haven't had people exploit this.

\$\endgroup\$
  • \$\begingroup\$ In Cjam, list of string is can be parsed using ~, while newline separated line can be parsed only with longer command (N%) \$\endgroup\$ – Akangka Dec 31 '15 at 4:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .