[email protected] (Ludovic Courtès) writes:
> [email protected] (Taylan Ulrich "Bayırlı/Kammer") skribis:
>
>> Yes, it still goes through the tests and fails at guix-environment.sh
>> with the same error. I repeated all steps from a new clone of master.
>>
>> taylan@T420:~/src/guix/build$ grep length guix-0.9.1/_build/sub/config.log
>> configure:6946: checking the length of the installed socket file name
>> configure:6969: checking the length of the socket file name used in tests
>> configure:6980: checking the length of a typical hash bang line
>> configure:6992: checking the length of a hash bang line used in tests
>> ac_cv_guix_hash_bang_length=73
>> ac_cv_guix_socket_file_name_length=74
>> ac_cv_guix_test_hash_bang_length=127
>> ac_cv_guix_test_socket_file_name_length=90
>
> Arff, I see. I’ve change LINUX_HASH_BANG_LIMIT in guix.m4 to 127
> instead of 128 to account for the trailing zero.
>
> This time it should detect the problem early.
Indeed, it fails with a meaningful error message at the beginning of the
check phase now.
> The “bad interpreter” message comes from Bash, in execute_cmd.c.
>
> However, that file does this:
>
> char sample[80];
>
> […]
>
> #if defined (HAVE_HASH_BANG_EXEC)
> READ_SAMPLE_BUF (command, sample, sample_len);
> sample[sample_len - 1] = '\0';
> if (sample_len > 2 && sample[0] == '#' && sample[1] == '!')
> {
> char *interp;
> int ilen;
>
> interp = getinterp (sample, sample_len, (int *)NULL);
>
> where READ_SAMPLE_BUF is:
>
> #define READ_SAMPLE_BUF(file, buf, len) \
> do \
> { \
> fd = open(file, O_RDONLY); \
> if (fd >= 0) \
> { \
> len = read (fd, buf, 80); \
> close (fd); \
> } \
> else \
> len = -1; \
> } \
> while (0)
>
> Now we know. :-)
Yay for hard-coded limits! :P
> Ludo’.
Taylan
