Adam Simpson’s Gem City JS presentation about Frontend Tooling prompted uneasyness about working in the command line. So we decided to face that fear for this month’s Dayton Clean Coders. The problem was one many have faced: take an archived project and get it up and running on a web server. Participants would need to automate downloading the file, extracting its contents, moving files into proper subdirectories, and starting the web server. As a bonus, it would be nice if the script could be easily modified for reuse.
References
Unexpected Cleverness
Despite varying levels of comfort in the command line, everyone settled on some form of pattern matching to work with files as sets, through either the find or mv commands. A noted absence here is anyone looping through the files in the project directory and handling them individually. Also of note is the use of the -exec switch in the find command present in two of the solutions. Beginners should take note of this seldom-seen feature in find, as it’s likely to be available on any *nix server you’ll ever use.
Runtime Feedback
We’d be remiss to not mention the appearance of say in one solution. Though this was an unorthodox approach, it highlights the importance of providing feedback as your script executes. If failure was reported at all in other scripts, it would have been in whatever output the shell command decided was appropriate. This sort of output can be difficult to interpret, especially for newbies to the command line. It is often a good idea to provide some kind of output along the way to confirm to your users that your script has started and/or completed some task to aid the debugging process.
Dayton Clean Coders meets once a month to work at making our code and workflows better. Does this sound like something that might interest you? Come and join us and maybe suggest a topic for a future meetup.
