3 ms·

Why is this insufficient for testing? $ strings /usr/local/musl/lib/libc.a | grep -i musl MUSL_LOCPATH As an aside, I love Rich Felker's POSIX shell trick

by chasil 5y ago

Why is this insufficient for testing? $ strings /usr/local/musl/lib/libc.a | grep -i musl MUSL_LOCPATH As an aside, I love Rich Felker's POSIX shell tricks. http://www.etalabs.net/sh_tricks.html http://www.etalabs.net/sh_tricks.html

R0b0t1 5y ago
Because it may not test the features of the installed system. I may not have a / available for my target.
andrewmcwatters 5y ago
Thanks for sharing this link. As soon as you start needing to read POSIX.* docs, you suddenly realize you need answers to a lot of basic questions. Sufficiently advanced shell scripts should be moved to a programming language, but until you hit that threshold, whatever one defines as appropriate, you still need some of these answered.
- chasil 5y ago
  If you need to coordinate activity between multiple systems in such a way that you are calling remote shells, then the shell is the place to run the show. I wrote an article on xargs parallel scripting some years ago that was popular here, and I can't imagine trying to do that in C. POSIX shells have great flaws. It is not LR-parsed language that can be implemented by a simple yacc grammar, and this leads to ambiguity. However, POSIX (as dash) is fast, portable, and small enough for embedded systems. Few of dash's peers are its equal if all of these are required.
  - andrewmcwatters 5y ago
    Totally. This is lost on a lot of developers. Even having a rudimentary knowledge of Shell Command Language saves a lot of otherwise wasted time.
MereInterest 5y ago
The general argument isn't so much about "testing" vs "macros", because #ifdef LIBRARY_VERSION is also a test of a macro's value, but what type of thing should be tested. Whether to test the functionality or the labels of it, whether to test the things that the computer runs or something that is part of a comment, whether you test the signifier or the signified. In this context, testing functionality would mean compiling a test program and observing the results. A macro or the existence of MUSL_LOCPATH would both be testing the labels and not the actual code.

by chasil 5y ago

R0b0t1 5y ago

Because it may not test the features of the installed system. I may not have a / available for my target.

andrewmcwatters 5y ago

Thanks for sharing this link. As soon as you start needing to read POSIX.* docs, you suddenly realize you need answers to a lot of basic questions. Sufficiently advanced shell scripts should be moved to a programming language, but until you hit that threshold, whatever one defines as appropriate, you still need some of these answered.

chasil 5y ago
If you need to coordinate activity between multiple systems in such a way that you are calling remote shells, then the shell is the place to run the show. I wrote an article on xargs parallel scripting some years ago that was popular here, and I can't imagine trying to do that in C. POSIX shells have great flaws. It is not LR-parsed language that can be implemented by a simple yacc grammar, and this leads to ambiguity. However, POSIX (as dash) is fast, portable, and small enough for embedded systems. Few of dash's peers are its equal if all of these are required.
- andrewmcwatters 5y ago
  Totally. This is lost on a lot of developers. Even having a rudimentary knowledge of Shell Command Language saves a lot of otherwise wasted time.

MereInterest 5y ago

The general argument isn't so much about "testing" vs "macros", because #ifdef LIBRARY_VERSION is also a test of a macro's value, but what type of thing should be tested. Whether to test the functionality or the labels of it, whether to test the things that the computer runs or something that is part of a comment, whether you test the signifier or the signified. In this context, testing functionality would mean compiling a test program and observing the results. A macro or the existence of MUSL_LOCPATH would both be testing the labels and not the actual code.