I noticed this problem as well: my first attempt failed, even though it worked on my machine, including with input that seemed like it was the same as the test cases. When I saved one of the test cases and ran file on it, I learned it had CRLF line endings. (Actually, as it turned out, just one line ending--the second line was unterminated.) Armed with this information, my second attempt was successful. I could alternatively have discarded the first line and foregone slicing the array; with input that adheres to the format given in the probem description, n may simply be ignored. Although my second solution passed, I probably wouldn't use it for a real-world task without further modification--it drops a trailing $'\r' from the first line of input, but not the second.

It seems to me that this should be considered a bug--in either the test cases for this problem or the Hacker Rank platform, depending on how the platform/encoding mismatch arose. The problem is not limited to the "Linux Shell" domain. In most cases, including real-world applications, a utility that processes text that it reads from standard input is generally justified in rejecting input that does not constitute well-formed text on the platform on which it runs.