To me, this looks right:

(for f in `find . -type f`; do basename $f; done;) | grep -e '^[0-9]' | sort

But it's not accepting the solution?

I tried the following response
find . -name *.txt | while read x; do sed -i 's/challenges are difficult//g' ;done

and this generated
Internal Server Error

Thanks for this it is fun

https://cmdchallenge.com/#/replace_text_in_files

This works for me on a Centos6 box but I get an Internal Server error here

find ./ -iname "*.txt" -print0 | xargs -0 sed -i 's/challenges are difficult//g'

I realize the files have spaces in the name - not sure why this is not working

thank you

If I try to use
rm **/*.!(exe|doc)
I get "syntax error near unexpected token `('"
That line is a valid bash expansion.

Oops... I'm a n00b. Please close this issue.

bash(0)> for i in *; do if grep 500 "$i" >/dev/null 2>&1; then echo "$i"; done
syntax error near unexpected token `done'
bash(2)>

all files that start with

meaning:

all files whose names start with

or

all files whose "contents" start with

It doesn't seem to be accepting

find . -name 'access.log*' | xargs grep -h -E '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}[0-9]' | awk '{print $1}'

But it accepts

find . -name 'access.log*' | xargs grep -h -E '([0-9]{1,3}\.){3}[0-9]{1,3}' | awk '{print $1}'

Print all files, one per line that contain
the string "500".

grep -R -m1 "500" does the trick. Instead, it outputs: "Internal Server Error".

This works: find . -name '*.txt' -type f -exec sed -i 's/difficult//g' {} +
so "challenges are difficult" is not checked as a whole

Apparently, the following command is accepted, while it shouldn't be.

head -n 15 README | tail -n 9 | sed "s/^# //g"

Fun game. I touched my mouse wheel to look at the scroll back buffer and noticed something is molesting the normal feel/speed of it. Plops on that! Please leave the scroll bars alone.

# Delete all of the files in this challenge
# directory including all subdirectories and
# their contents.
# 

i responded with rm -rf * and it didn't work. whoami says i'm root so... either i'm missing something obvious... or this isn't working right

it responded with False though, which is odd...

bash(0)> rm -rf *
False

I'm on the initial exercises where I'm supposed to search for patterns within the files starting with "access.log" and I've tried several commands that didn't work but they all work on my local pc.

The error message says that the file access.log doesn't exist.

Normal GNU ls doesn't display one file per line but puts multiple files onto the same line. That's why I thought you specifically asked for ls -l but I was suprised it didn't work. Then I tried ls -l | cut -d" " -f9-, maybe you only wanted the file names, but that didn't work either.

bash(124)> grep -Ril "500" /var/challenges/search_for_files_containing_string
/var/challenges/search_for_files_containing_string/access.log
/var/challenges/search_for_files_containing_string/access.log.1
/var/challenges/search_for_files_containing_string/README

find . -name '*.log' doesn't work as a valid solution for this problem.

This seems to be a valid answer to the challenge "Print Number Sequence"
echo {1,2,3,4,5,6,7,8,9} {1,2,3,4,5,6,7,8,9}{0,1,2,3,4,5,6,7,8,9,0} 100

search_for_files_containing_string

I'll leave the command out to leave a spoiler unless it's all that important.

Here's the output I get.

# Print all files, one per line that contain
# the string "500".
# 
bash(0)> # Command elided
./access.log
./access.log.1
./README
bash(0)>

do I need to strip the ./?

Expected behavior

Given the following instructions for the module search_for_files_containing_string:

# Print all files, one per line that contain
# the string "500".

The command:

grep -l 500 ./*

Which outputs:

./README
./access.log
./access.log.1

Should be a valid alternative correct answer.

Observed Behavior

The command:

grep -l 500 *

Which outputs:

README
access.log
access.log.1

is the only valid answer.

Possible Investigation Area

I believe the lines here may be the key.

I'm not sure enough how this is implemented if multiple answers can be correct, however, I believe that the ./ addition to most commands that work on a path is good practice. After all, Explicit is better than implicit.

The blue and green colors against the dark background are hard to read, especially the challenge question itself. I think more contrast would help, or maybe make it possible to choose color schemes.

The Ctrl + d key combination is a logout command if no characters are present, otherwise it is a delete-forward command.

Wanted to start testing ... do I gave the rm -rf an .* instead of an .??*
The .* geve a nice error.
Issuing rm -rf .??* yielded an internal error.
Subsequent test shows that it does not digest the .??* pattern

bash(0)> rm -rf *
False
Test failed, files or directories remain.
bash(0)> rm -rf * .*
+ rm -rf README animi.doc atque.wav aut.webm beatae.flac blanditiis.avi consectetur.pdf consequuntur.jpeg corporis.xls deleniti.gif dicta.wav dignissimos.css dignissim
os.jpg dolor.doc dolorem.doc dolorem.xls dolorum.wav error.wav excepturi.png exercitationem.mp3 expedita.jpeg expedita.xls hic.xls id.txt ipsa.xls iusto.gif libero.xls
 maxime.mp3 mollitia.odt necessitatibus.css nisi.avi non.gif numquam.xls odit.doc omnis.txt perspiciatis.mov provident.avi quia.jpg quidem.wav saepe.doc sit.avi suscip
it.wav temporibus.doc totam.avi var voluptates.wav voluptates.xls . .. .config .dont.forget.dotfiles
rm: refusing to remove '.' or '..' directory: skipping '.'
rm: refusing to remove '.' or '..' directory: skipping '..'
bash(1)> rm -rf *
False
Test failed, files or directories remain.
bash(0)> rm -rf * .??*
Internal Server Error
bash(☠️)> 

The kernel running on the website is 4.7.3, while the oldest barely supported kernel is 4.8.17 with 4.9.6 being suggested.

I would presume the ancient version is due to coreos only having it, but is there any possibility to have a more up to date server?

Sources: https://kernel.org/
[code]uname -a[/code]

EDIT: for that matter, uname has no reason to be exposed :P

Apparently it doesn't check for the presence of files.

I tried many answers:

• rm -fr
• rm -fr ./*
• rm -fr *
  But none of them do the work. I tried deleting a single file, but it remains where it is

I don't think I experienced this before the last update, but since the print_common_lines challenge update, any error in a chain of commands now aborts the rest of the script.
I.E.:

bash(0)> false; echo hi
+ false
bash(1)>

Or, more likely to happen with these tests, a grep that doesn't match (minor spoilers?):

cat somefile | while read line; do grep "otherfile" -e "$line"; done;
+ read line
+ cat somefile
+ grep otherfile -e someline
bash(1)>

One can work around it by adding || true or set +e:

bash(0)> cat somefile | while read line; do grep "otherfile" -e "$line" || true; done;
bash(0)>
bash(0)> set +e; cat somefile | while read line; do grep "otherfile" -e "$line"; done;
bash(0)>

I have no idea what I'm doing wrong... It's possible none of these would work, but I've been able to execute things without an error on earlier steps.

# Extract all IP addreses from files that
# that start with "access.log" printing one
# IP address per line.
# 
bash(0)> find . -iname 'access.log*' | xargs egrep -h -o '[0-9]+[.][0-9]+[.][0-9]+[.][0-9]+'
Internal Server Error
bash(☠️)> egrep -h -o '[0-9]+[.][0-9]+[.][0-9]+[.][0-9]+' `find . -iname 'access.log*'`
Internal Server Error
bash(☠️)> grep -h -o '[0-9]+[.][0-9]+[.][0-9]+[.][0-9]+' `find . -iname 'access.log*'`
Internal Server Error
bash(☠️)> for f in `find . -iname 'access.log*'`; do grep -h -o '[0-9]+[.][0-9]+[.][0-9]+[.][0-9]+' $f; done
Internal Server Error
bash(☠️)>

There are a few of the challenges like this that I can't seem to find a command that doesn't produce an internal server error... In 'replace_text_in_files' some lines as simple as echo a are returning an error.

bash(☠️)> print "hello world"
Internal Server Error
bash(☠️)> echo
Internal Server Error

For sum_all_numbers, I tried the following:

cat sum-me.txt | tr '\n' '+' | sed 's/\+$//' | bc

For some reason, this prints no output and exits with status 0. echo '1+2+3' | bc outputs 6 as expected, so the only thing I can think of is that the answer is being swallowed somehow.

For whatever it's worth, I eventually wound up solving the challenge with:

echo 42

which I would expect to produce the same output, and which succeeded.

bash(0)> cat war_and_peace.txt |sed -e 's#![!]*#!#g'|sed -e 's# !# #'|sed -e 's#! ([a-z])# \1#g'|sed -e 's#([a-z])!([a-z])#\1\2#g'|sed -e 's#!.!#.#'
Command is too long.

this challenge, including the solution in the yaml, does not account for spaces in filenames.
As this problem is very often an issue, a file with blanks should be in the list.

To Reproduce

1. Type ??.
2. Press Enter.

Currently, print_common_lines challenge reads:

access.log.1 and access.log.2 are http server logs. Print the IP addresses common to both files, one per line.

The following answer is not accepted:

17.137.186.194
2.71.250.27
28.151.137.59
108.68.174.15

but the following (which is achieved by the same command followed by | sort) is:

108.68.174.15
17.137.186.194
2.71.250.27
28.151.137.59

Tried this:
Even though the solutions seems to be correct, no error was thrown.

find . -type f | while read line; do new=echo $line | cut -d. -f2; mv $line .$new 2>/dev/null ; done

Thanks!

I was trying to resolve

https://cmdchallenge.com/#/remove_files_with_extension

but it says that there are 5 doc files but when I try to
find . -type f -name '*.doc'

Only appears 4, is there a problem or I don't know if the result is correct?

Thanks

bash(0)> tail -n 5 access.log
Internal Server Error
bash(☠️)>

All in the title.
It prints file names as well as the lines containing "500" but does not pass the "test".

# The files in this challenge contain spaces.
# List all of the files in the current
# directory but replace all spaces with a '.'
# character.

The filenames in this challenge...

When you press CTRL-L you lose your current instruction.

bash(0)> find ./ -type f -maxdepth 1
ls -a -1

As it is now, I think it would miss dotfiles, so it's a bit misleading.

Otherwise cool game, thanks!

See below. My first solution is correct to the language in the challenge but was not solving it. So I thought maybe the expectation was numerically sorted, which also did not solve the challenge. Finally, I lexically sorted and that was correct.

For challenges where the stdout is simply compared directly to some solution text (i.e. order matters), the question should outline the order expectations.

There is a similar issue in remove_duplicate_lines in that a simple cat | sort | uniq doesn't work so on a whim, I tried an awk solution that maintained initial order and it was correct.

# You have a new challenge!
# access.log.1 and access.log.2 are http server logs. Print the IP
# addresses common to both files, one per line.
# 
bash(0)> cat access.log.1 access.log.2 | awk '($1 in array) { print $1 }; array[$1]'
17.137.186.194
2.71.250.27
28.151.137.59
108.68.174.15
bash(0)> cat access.log.1 access.log.2 | awk '($1 in array) { print $1 }; array[$1]' | sort -n
2.71.250.27
17.137.186.194
28.151.137.59
108.68.174.15
bash(0)> cat access.log.1 access.log.2 | awk '($1 in array) { print $1 }; array[$1]' | sort 
108.68.174.15
17.137.186.194
2.71.250.27
28.151.137.59
# 👍 👍 👍  Correct!

Can we have an ISSUES file to describe how to file an issue without spoilers, and describe how to get help with specifics outside of the issue, or is that unreasonable for the github repo?

Seeing parts of challenge solutions seems fine, but having the whole thing there ruins my personal curiosity as a user while I'm paying attention to the project as a developer and interested chum.

Currently your example in https://github.com/jarv/cmdchallenge/blob/master/challenges.yaml uses ls to count files. This will not work for hidden files.

Better to allow people to get in the habbit of using find . -type f for things like counting.

Including hidden files might be one way to make people think about that.

I'd like to contribute some improvements to the website itself (in particular, adding some files to tab completion); would you consider including the client-side bits?