Sorry to the both of you, sincerely. I really did not mean for my email to sound like a rant, or pointing fingers. I was merely excited to pinpoint the problem that many of my friends have been ranting to _me_ about, and my misplaced enthusiasm, coupled with the fact that it was 4am (when I'm most productive and least coherent) might have made the email sound aggressive.
Back to the issue, both of bash's built-in testers "[" and "test" report existences of the file descriptors 0, 1, and 2 instead of the files themselves (/dev/stdin, stdout, and stderr). Udev needs to be able to actually test and see if these files (not descriptors) exist yet. I understand the reasoning for checking the descriptors instead of the files, but that feature already exists for "test -t 0," whereas there is currently no other bash-builtin way to check the file /dev/stdin itself. And, as previously mentioned, the binaries /usr/bin/[ and /usr/bin/test, which work properly, might not be available at the time this script is run. Unless there is another builtin way to check the existence of these files themselves, the only way the problem can be remedied from udev's side of things is by using a different shell. Bash, however, is duplicating this specific feature, and if a user wanted to check the file descriptors, they could use "test -t n" instead of specifying the /dev filename. I guess I just don't see the purpose in providing this feature twice while making it impossible to check /dev/stdin the file itself. If there are any other ways of accomplishing this that I'm not aware of, I'd be happy to hear them. Again, this isn't a rant or an attack, I just want to see this issue get resolved, and I'm open to hearing your reasoning on it. Thanks, Jacob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
