1

I was trying to convert a bash script to binary using shc. I put in a colored help page like this:

#!/bin/bash
if [ "$1" = "--help" ]; then
    echo -e "\e[0;31m———————————————\e[0m"
    echo -e "\e[0;33m  Script help \e[0m"
    echo -e "\e[0;31m———————————————\e[0m"
    echo -e "\e[0;34mOPTIONS\e[0m"
    echo -e "\e[1;33m--help\e[0m"
    echo -n "   "
    echo -e "\e[0;33mAccess this help page.\e[0m"
    echo -e "\e[0;31m———————————————\e[0m"
    exit 0
fi

When I tested it normally, it was working fine all the time. But then I converted it to binary with shc -T -f script, and now every other time I run ./script.x --help it gives me this error message:

dyld: Library not loaded: /usr/local/opt/readline/lib/libreadline.6.dylib
  Referenced from: /bin/bash
  Reason: no suitable image found.  Did find:
    /usr/local/opt/readline/lib/libreadline.6.dylib: open() failed with errno=24
Trace/BPT trap: 5

What happened?

rici
  • 234,347
  • 28
  • 237
  • 341
raumaan kidwai
  • 356
  • 1
  • 4
  • 14
  • Are you using OS X or is this about iOS? I might have gotten the tag wrong, and it is important to know which OS you are using. – rici Mar 26 '15 at 16:02
  • Error 24 in OSX is "EMFILE", which means "too many open files". You might be able to change the limit with `ulimit -n`. Apparently, the OSX open file limit is quite low, but I have no idea why trying to start up bash would exceed that limit. – rici Mar 26 '15 at 16:11
  • I'm going to assume that the "compiled" script is playing games with temporary files/etc. before it spawns a shell to run the "compiled" code. – Etan Reisner Mar 26 '15 at 16:21
  • @EtanReisner: Quite possible, but even so using 64 FDs seems a bit extravagant. Of course, it's quite possible that the dynamic loader is also careless about how many fds it uses. – rici Mar 26 '15 at 16:36
  • Alright, so `ulimit -n` echoes back 256, and the script doesn't interact with any temporary files. Weird. – raumaan kidwai Mar 26 '15 at 17:05
  • Also, apparently OS X doesn't allow `ulimit -n `. – raumaan kidwai Mar 26 '15 at 17:07
  • Update: `sysctl -w kern.maxfiles=65000` fixed it. – raumaan kidwai Mar 26 '15 at 17:16

1 Answers1

0

Alright, so if anyone else is reading this with the same problem, I found a solution:
sysctl -w kern.maxfiles=65000
It's apparently an alternative of ulimit -n that OS X allows. But it's still a mystery as to why it's necessary in the first place...

raumaan kidwai
  • 356
  • 1
  • 4
  • 14