Clear the text in the shell script box (highlight the text with your mouse cursor and hit Backspace) then copy and paste the following text into the same area:
Bash:
echo Words:
echo $1 | wc -w
echo Characters including spaces:
echo $1 | wc -c
I love the simplicity here! However, the `wc` command has a longstanding bizarre quirk since the birth of UNIX where it pads its result with spaces and a newline. This is both ugly and incompatible with inline output (the result must occupy its own line independently). Additionally, the characters code is also afflicted with an incorrect output; it returns the number of characters + 1.
I would like to suggest the following code instead, which compensates for these anomalies and gives the reader more flexibility/choice about using inline results or newline results:
Bash:
echo $(echo $1 | wc -w) words
echo $[$(echo $1|tr -d ' '|wc -c)-1] "characters (no spaces)"
echo $[$(echo $1 | wc -c)-1] "characters (with spaces)"
## Output for "Hello World!" ##
# 2 words
# 11 characters (no spaces)
# 12 characters (with spaces)
Now regarding the accuracy, the user was inquiring on if anybody had done any testing:
Has anyone actually checked how exact this is? I'm testing it now and the "characters including spaces" count seems to always be one more than it should be… Can anyone confirm if it's working 100% properly or not on their mac?
I know it's not a 'huge deal', and I can just manually deduct 1 myself, but it'd be interesting to know if anyone else is experiencing this and if so, if there's a way to get it exact.
Yes, indeed, the `wc` command is off by 1. See the code I've posted for the correction to resolve this.
However, I have done some other testing, and the results vary. For example, with CJK characters are assumed to be 3 characters each (after compensating for the +1 bug); The Japanese word "好き" is considered to be 6 characters instead of 2. So be cautious.
This seems like a terrible idea because I don't believe input into the shell script is sanitized. A malicious string, perhaps something like "lol ; evilcommand" could cause "evilcommand" to be executed, enough to recursively delete everything in your home directory.
I think you might be right; raw unsanitised text could exploit a BASH shell script vulnerability. I'm not sure how your post was overlooked by so many other readers/commenters. I tried to do some "evil commands" without success, so perhaps Automator itself sanitises the text. Somebody should investigate this further!
But for now, people probably aren't going to character-count code, so even if this potential vulnerability does exist, it's unlikely to eventuate in my opinion.
＝＝＝＝＝＝＝＝＝＝＝
ＢＯＮＵＳ ＣＯＤＥ！
＝＝＝＝＝＝＝＝＝＝＝
So, maybe you're a little particular about the final output dialogue not having text in the "Title Bar", and having two buttons "[Cancel] [OK]" when only one is necessary. Instead of using Automator's "Ask for Confirmation" dialogue, you could use the following Applescript instead:
AppleScript:
on run {lstInput}
## input is a "list" variable type, so you need to convert it to a string:
set {text item delimiters, TID} to {"
", text item delimiters} ## This ugly line break is a literal new line character, needed as the delimiter
set {text item delimiters, strInput} to {TID, lstInput as text}
display dialog strInput with title "Word Count" with icon note buttons {"OK"} default button 1
end run
