I really like this; reminiscent of the Python Challenge, but for shell.

You should support bash's double-star wildcard, which works recursively. Several of the challenges that currently require

    find -name 'access.log*' -print0 | xargs -0 somecommand

could just use

    somecommand **/access.log*

instead.

You might also encourage people to look up manpages. For instance, someone who doesn't know about "grep -h" may want to look at the manpage for grep. You could make "man grep" link to http://man7.org/linux/man-pages/man1/grep.1.html .

Tab completion doesn't always include all files; for instance, it doesn't include split-me.txt

Have you considered logging all unique successful solutions (filtering out minor whitespace differences) to each challenge? That would let people who have completed each challenge see other potential approaches to the problem, and perhaps learn about new commands.

> You should support bash's double-star wildcard, which works recursively

It depends on what the educational goals are, but alternatively OP could swing on the opposite direction and go with a very vanilla POSIX sh style shell (maybe dash) to discourage bashisms.

I might of course be bit biased because `find` is one of my favorite utils (generally with -exec instead of -print0|xargs -0) and I practically never use newfangled doublestar globbing

Teaching efficient bash usage and teaching portable shell scripting seem related but distinct. This challenge specifically mentions that it uses bash.

Yes sure, I wasn't trying to say that going full bash is a bad thing. I was merely presenting an alternative.

Ah good point, the commands are run in a bash 4 subshell actually but by default the globstar option is off.

globstar is on by default now so this will work.

> I really like this; reminiscent of the Python Challenge, but for shell. > You should support bash's double-star wildcard, which works recursively. Several of the challenges that currently require > find -name 'access.log' -print0 | xargs -0 somecommand > could just use > somecommand /access.log

This challenge was where I stopped, and for this exact reason. Then again, I am a zsh user, so maybe I'm spoiled...

I stopped after 'Print the relative file paths, one path per line for all files that start with "access.log" in the current directory.' It didn't like my BSD find options.

> It didn't like my BSD find options.

Which options, specifically?

You can use

  shopt -s globstar

and

  **/access.log*

works just it would in bash :)

I actually submitted a PR upstream, and the author merged it and deployed it, so cmdchallenge.com now has globstar enabled.

The finale was weird for me, kinda anticlimactic (back to "hello world"); is that how it's expected to behave? No "finished" message or something? Or is my NoScript interfering somehow?

    She is betraying us! Russia alone must save Europe.
    Our gracious sovereign recognizes his high vocation
    and will be true to it. That is the one thing I have
    faith in! Our good and wonderful sovereign has to
    perform the noblest role on earth, and he is so virtuous
    and noble that God will not forsake him. He will fulfill
    his vocation and crush the hydra of revolution, which
    has become more terrible than ever in the person of this
    murderer and villain!
    #     Correct!
    # You have a new challenge!
    # Print "hello world".
    # Hint: There are many ways to print text on
    # the command line, one way is with the 'echo'
    # command.
    # 
    # Try it below and good luck!
    # 
    bash(0)> printf "hello world"
    hello world
    #     Correct!
    bash(0)>

  # Print "hello world".
  # Hint: There are many ways to print text on
  # the command line, one way is with the 'echo'
  # command.
  # 
  # Try it below and good luck!
  # 
  bash(0)> echo '"hello world".'
  "hello world".
  bash(0)>
  

What is this, Android? Sheesh.

Nach dem Spiel ist vor dem Spiel?

https://en.wikipedia.org/wiki/Sepp_Herberger#References_in_p...

(I would also like it if the site somehow indicated that you got to the end or congratulated you on finishing everything.)

I honestly didn't think anyone would complete all of them :) I'll put something cool at the end, thanks for the suggestion.

I was on the 3rd challenge, listing files in a directory, one per line, and it didn't accept "ls -l", but it did accept "ls"

Same. Seems like the wording on some questions could use tweaking. Not bad overall, though.

If anything, i'd argue that it's incorrect. I first tried `ls -l`, then realized "oh, there could be hidden files so `-l` is not correct. Yet, `ls -la` failed too.

To list "all files", you'd need to include hidden right? Well, to be sure, at least.

I took this to mean it wanted only filenames and nothing else. I used:

    ls -1

Yeah it's particular about the output that it expects.

I guess my point is that "ls" shouldn't be an answer. Typically it will print out multiple files on a line. If it's just checking for output and not the actual command someone entered, there should probably be more than one file in the directory to show that it will actually print one file per line.

The mostly correct answer is `ls -1`. Just mostly, because it falls to the classic unix trap (filenames can contain almost anything) which also shows that the challenge is ill defined. What is the expected result if the filename contains newlines?

And this is not just some hypothetical scenario, just today at work I encountered a file with cursor movement terminal escape sequences in the filename.

`ls -1b` should work correctly in your case. Option -b (or --escape) enables C-style escapes. IMHO, it should be on by default.

Because it is executed outside of a terminal (the execution isn't in javascript) you get a single column output. Probably would be better to be more specific in the descriptions, thanks for the suggestion.

Although it often doesn't get printed like that, shells do consider the output of `ls` to be multiple lines. Try doing `ls > foo.txt` and looking at the output file (or more directly, `ls | wc -l`).

That isn't the shell considering the output one per line.

ls will change the way it writes its output if it detects that stdout is a tty versus a pipe or redirect.

It seems to accept any command that produces the expected output, though. That question should specifically say that it only wants the filenames, which would make it clear that `ls -l` doesn't produce the desired result.

Super-cool! Some pieces of feedback:

1) It would be nice to have something special happen when you solve all the puzzles, rather than going back to the first. Some javascript balloons dropping from the ceiling? ;_)

2) Some of the problems, it's hard to tell why an answer doesn't work. A side-by-side diff showing my results compared to the expected results might help?

3) After solving (perhaps just one, or maybe all), I'd love to see other people's solutions. That'd be quite educational.

I really enjoyed this, it was a nice way to practice/learn some command line tricks. In particular I got better acquainted with the find command. Nice work! My only suggestion would be to have an option to show a solution (yours or perhaps even a user-submitted one) if you get stuck on a particular challenge.

    grep -rl 500 .

wasn't accepted. Am I wrong or is it wrong?

Only filenames matching access.log should be returned.

Unfortunately, since shopt globstar is disabled I ended up needing to do this:

    grep 500 $(find . -type f -iname "access.log*")

You could also include "shopt -s globstar; " at the beginning of your line.

grep -r 500 --include access.log

That returns the filenames in the format "./access.log" but it wanted "access.log". It's a bug.

I used echo -e 'access.log\naccess.log.1\nREADME'. :D

Gotcha. Thanks.

Hahahaha I did the exact same thing

You are: grep matches strings, not integers.

    grep -rl '500'

works just fine.

There is no concept of an integer on an argument vector. Quoting in bash just escapes IFS characters (usually whitespace) to control whether to include them in a given argument on the vector, but these arguments (as passed to exec) are always character strings (with or without quoting).

Interestingly enough

grep -rl "500" .

doesn't work because it returns with the "./".

After completing the challenges (only had to lookup references on bash parameter expansion and how to read lines without parsing them), I would say that it might be helpful to have some reference information available whether via clicking to a third party URL. It'd also be _really_ nifty to be able to compare my solutions against others' solutions.

I'm making something related as a side project too, and the major problem I have right now is showing a terminal on the page. As you can see I'm relying on archaic methods... https://term.surge.sh

Have you considered running the commands directly in JavaScript, rather than via AWS? With some work, you could run everything inside emscripten in the browser, and then you don't need to worry about security, sandboxing, or scaling.

In this case you'd probably be better "just" going for http://stackoverflow.com/questions/6030407/how-does-linux-em... ?

Yeah though this was pretty easy to setup and I was looking to replicate an authentic command line experience including the standard unix utilities.

It looks a bit like the cwd is shared between multiple users accessing the site? I suddenly got errors that access.log disappears, after which my pwd seemed to randomly change.

Nothing is shared in fact every time you submit a command you get a new subshell in a new container. If it is reproducible I will track down the problem.

Fun! Needs tab-complete.

I tried "rm -rf". Not sure if it worked.

I got stuck on this one too. Strangely "find . -delete" worked fine. I'm getting Internal Server Error" now, so perhaps a victim of it's own popularity?