0

I have this little bash script:

readonly imagick_extension=$(cat "${php_configuration_file}" | grep imagick)
echo "Imagick extension grep value: $imagick_extension"
if [ "${imagick_extension}" != "extension=imagick.so" ]; then
        echo "ERROR: Imagick PHP extension is not enabled!"
        exit 1
fi
echo "Imagick PHP extension is enabled."

And the output is:

Imagick extension grep value: extension=imagick.so
ERROR: Imagick PHP extension is not enabled!

How is this possible?

  • It says that the variable's value IS extension=imagick.so,

  • but it still goes into the if clause where it should only go if it ISN'T extension=imagick.so

Thanks in advance!

4
  • 2
    You created the PHP configuration file on a Windows system, so lines have an invisible trailing CR. Prove this with echo "Imagick extension grep value: < $imagick_extension >" and looking to see if the output is >agick extension grep value: extension=imagick.so (notice the first couple of characters)
    – roaima
    May 20 at 9:15
  • @roaima Yes, the output is " >agick extension grep value: < extension=imagick.so". How does this work? Why is this the output? And how could I fix this? Thanks! :)
    – Tudvari
    May 20 at 9:25
  • Run dos2unix over the file, it will correct the line-endings for Unix/Linux use.
    – AdminBee
    May 20 at 9:27
  • FWIW, a straight test like that will also be sensitive to trailing white space, try with e.g. readonly imagick_extension='extension=imagick.so '.
    – ilkkachu
    May 20 at 9:36

1 Answer 1

2

The problem here is that you have a PHP configuration file that you created on Windows. As a result its line ending are CR/LF rather than the UNIX standard of LF.

You can prove this by modifying your echo command like this

echo "Imagick extension grep value: < $imagick_extension >"

As confirmed in a comment you see that the output has the last space and > at the beginning of the line, showing that there is indeed an embedded newline character in the value:

 >agick extension grep value: extension=imagick.so

The easy solution is to convert the file to UNIX format:

dos2unix /path/to/php_configuration_file.ini

Or if you don't have the easy dos2unix command, this sed alternative:

sed -i 's/\r//' /path/to/php_configuration_file.ini

I'm sure there are duplicate answers elsewhere on UNIX&Linux but I can't find them. The closest I've got so far is this related one that gives more detail

5
  • I've thought about collecting all the CR issues to one question, but there'd be no way to give it a descriptive searchable title, since the errors and issues it can lead to are so varying... Maybe I'll try to get on with it again...
    – ilkkachu
    May 20 at 9:39
  • @ilkkachu you'd need a solution-focussed title, I suspect. "Windows files don't work properly on UNIX/Linux systems", but even that's not quite right because Mac files won't work properly on UNIX/Linux systems, and U+L files won't work properly on Mac. And that's a way too convoluted title to be useful
    – roaima
    May 20 at 9:47
  • @ilkkachu I kind of like the title of the (main) one about this on stackoverflow: "(Are shell scripts sensitive to encoding and line endings?" But it's clearly not very searchable, because new questions about problems with line endings get posted all the time. May 20 at 9:52
  • @roaima, though Macs have been pretty much Unixen for a while now (since OS X was released in 2001??). I'd expect anyone using a "classic" Mac by now would be in the know about quirks like that. Anyway, a lone CR as a line ending would be far less subtle on Unixes, you'd get all lines printed on top of each other even when just catting the file out...
    – ilkkachu
    May 20 at 10:25
  • @GordonDavisson, the main problem there is that the people with the problem don't know the cause. If they knew it was about line endings, or Windows, they wouldn't need to ask why their script gives weird errors, why their text data gets (seemingly) corrupt, or here, why their strings don't match. But yeah, that's pretty much the only sensible to thing to raise to the title.
    – ilkkachu
    May 20 at 10:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.