I am building a Shortcut where I compare a string that is passed into the Shortcut (var1) with a string created by operations in the file (var2) . I then test the “if var1 is var2” and the test fails. When I attempt to debug this using show result it appears that a CR or LF or something similar has been inserted. This was done by using the following as the result being shown example “Show Variable 1->var1<-“. The window that appears has the → and ← on different lines than the text for var1 and the leading → on the same line as the text for var2.
If instead I use if var1 contains var2 the test works fine.
Just wondering if others have seen this behavior, debugging is a bit painful.
Yes, that sounds frustrating, but it is correct if the strings don’t match, no? Is using ‘contains’ for the comparison a working solution for you? Otherwise, I’d suggest using ‘replace’ to clean up your input strings.
What is producing the input for the shortcut? It seems like the root cause of your issue is based there and so would be worthy of the first look in case you reuse it in other places and your issue would carry over to those too.
Thanks akerr and sylumer for replying!
So the bigger picture is that occasionally I download a program for which developer has provided a hash (e.g. ExifTools). I built the Shortcut to allow me to select the hash, copy it (at least on the Mac) and then launch the Shortcut. It will then prompt me to select the file, then select the hash algorithm to use, and then compute the hash using shell commands (on the Mac). Then it compares the computed hash with the expected hash passed into the Shortcut. This comparison is where things broke down. The two hashes while visually identical when printed out using Show Result were not the same when compared in the shortcut. Turns out they were different (as might be expected).
To debug things I wrote out each of the two hashes bracketed with angle brackets to try to ID invisible characters using Show Result for each hash. The Show Result then decided on its own to wrap the lines of text at the angle brackets and the wrapping was different in the two cases and this messed me up. I eventually found that the result returned from computing the hash in the shell had a return character in it. So once identified I now remove it and all now works as intended. I am not sure if this return character is due to something I have done or is intended behavior when returning the hash from the shell. Will try to figure that out someday when I have free time.
I know this tool is intended to support people with varying skills but I am hoping Apple provides a few more tools to support debugging. Being able to pause and inspect would be quite helpful.
Any chance your shell commands are using, say, echo without the -n parameter to force the automatically added trailing newline to be removed? If so, add in the missing parameter.
I do not think so. I am simply passing the file to be hashed to standard input of md5 or shasum -a 1, etc using Run Shell Script and then setting a variable from the result.
The attached screenshot contains the part of the shortcut that runs the shell command. Prior to the dictionary definition I have selected the hash algorithm which I use as the key. Perhaps it is a zsh behavior (I have not used it much but Apple is using it as default now for MacOS so I kept it).
Don’t I feel silly. I did not even realize there was a Generate Hash action in Shortcuts. I was so focused on how I would evaluate hashes on MacOS I missed this and just found it while I was trying to figure out how to run this shortcut on my iPad. Gray hair got me again!
First of all, do you know Shortcuts has a built-in hash function you could use? That might make things a little simpler.
EDIT: I see you have now spotted that while I was putting together my answer regarding the command line.
But, assuming you do need to do something at the command line, what you have is not using an echo, but if you were using shasum -a 1 with the standard input, that would use a - placeholder as the filename for stdin, and automatically add in a new line at the end - commands often do that to make stdout more atomic in terms of line processing. To remove those at source, you could, for example, modify the command to this.
shasum -a 1 | cut -d " " -f 1 | tr -d "\n"
The first addition (cut -d " " -f 1) trims out the file name, and the second addition (tr -d "\n") removes the extraneous newline.
If you need the filename placeholder for some reason (it isn’t the filename remember, only the stdin placeholder, so it holds no meaningful value), simply remove the first addition and one of the pipe characters.
Of course since you are calling single commands, there’s no real potential for reuse anywhere else, so applying a replacement in the shortcut in this instance would be equally valid as it is effectively also at source, the full “script” being defined in the shortcut rather than external to it.
Decades ago I wrote shell scripts but do not recall running into this sort of thing but my application at the time was different. I will keep this in mind as I suspect I may want to run some more from the command line in the future.
You’ve been quite helpful sylumer!