Re: [RFC] test: Old shells and physical paths
Hi, On Thu, Dec 20, 2012 at 12:01 AM, David Aguilar dav...@gmail.com wrote: Do you know if the differences are relegated to cd, or do other common commands such as awk, grep, sed, mktemp, expr, etc. have similar issues? There are almost certainly going to be incompatibilities with other commands. The system implemented UNIX95 plus some extensions, then they began supporting UNIX03/SUSv3/POSIX.1-2001/whatever for certain commands by using an environment variable to toggle between the incompatible behaviors. Their documentation on the UNIX03 commands indicates it is still only partially supported. For example: cp supports -L and -P, but cd doesn't. I wonder if it'd be helpful to have a low-numbered test that checks the basics needed by the scripted Porcelains and test suite. It would give us an easy way to answer these questions, and could be a good way to document (in code) the capabilities we expect. I'd be in favor of something like this as well. Thanks. David P.S. In the meantime, I am handling the cd situation by replacing -P with $PHYS and prepending the following to t/test-lib.sh. set +o logical /dev/null 21 || PHYS=-P -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] test: Old shells and physical paths
David Michael fedora@gmail.com writes: In working on a port, I have to tolerate an ancient shell. The cd and pwd commands don't understand the -P flag for physical paths, as some tests use. The biggest offender is cd -P causing a failure in t/test-lib.sh (since 1bd9c64), which is sourced by every test script. Is here is a nickel, get a better shell an option? Running tests is one thing, but I'd be worried more about scripted Porcelains broken by a non-POSIX shell if I were you. Would it be acceptable to instead force the platform's shell option (if it exists) to always use physical paths for the tests and drop the -P flags? As a patch to the source files in my tree? Not likely, even though I cannot say for sure without looking at how the change would look like. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] test: Old shells and physical paths
Hi, On Thu, Dec 20, 2012 at 12:17 AM, Junio C Hamano gits...@pobox.com wrote: Is here is a nickel, get a better shell an option? It is, somewhat. There is a pre-built port of GNU bash 2.03 for the platform, but I was trying to see how far things could go with the OS's supported shell before having to bring in unsupported dependencies. Unfortunately, I do not believe the OS fully conforms to POSIX.1-2001 yet, so that means no -P or -L without going rogue. I'll carry test fixes for this platform locally. Thanks. David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] test: Old shells and physical paths
On Wed, Dec 19, 2012 at 6:28 PM, David Michael fedora@gmail.com wrote: Hi, On Thu, Dec 20, 2012 at 12:17 AM, Junio C Hamano gits...@pobox.com wrote: Is here is a nickel, get a better shell an option? It is, somewhat. There is a pre-built port of GNU bash 2.03 for the platform, but I was trying to see how far things could go with the OS's supported shell before having to bring in unsupported dependencies. Unfortunately, I do not believe the OS fully conforms to POSIX.1-2001 yet, so that means no -P or -L without going rogue. I'll carry test fixes for this platform locally. Do you know if the differences are relegated to cd, or do other common commands such as awk, grep, sed, mktemp, expr, etc. have similar issues? I wonder if it'd be helpful to have a low-numbered test that checks the basics needed by the scripted Porcelains and test suite. It would give us an easy way to answer these questions, and could be a good way to document (in code) the capabilities we expect. -- David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
