Talk:Bad command or file name
This article was proposed for deletion. See Wikipedia:Votes for deletion/Bad command or file name for a record of the votes and discussion; the result was a lack of consensus to delete. Postdlf 23:10, 10 Feb 2005 (UTC)
God damn it, if Wikipedia deletes one more article, I'm gonna go beserk. I hate coming back to wiki for information only to realize that some snooty jackass deleted the article. I bet you the article count is actually dropping on wiki because of all the snooty jackasses. Keep this article dammit.
- Well said, anonymous! I added an image of Windows XP error - can someone place it properly, thanks Travis (talk) 05:39, 11 December 2007 (UTC)
Fair use rationale for Image:Win xp cmd bad command.png
Image:Win xp cmd bad command.png is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.
Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.
If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images lacking such an explanation can be deleted one week after being tagged, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.
B4d (0mm& 0r /-1!3 n@m3
Edits - March 3
- Original research tag justification: There is no evidence for paragraph 2, note 2 is NOT a source, and note 2 is a specific example and does NOT represent unices as a whole.
- Windows NT (and newer): There is no successor to Windows NT family (yet). Windows 10 is still part of the Windows NT family, and so are Windows XP, Vista, and 7.
- General fixes: Readability improvements were made and some of the unclear antecedents were fixed.
- Tense changes: I'm not sure what tense guidelines are for WP, but I changed some of the tenses anyway.
- Note 2 didn't make much sense with the ambiguous pronouns; I (this is a shared IP, so expect vandalism from idiots) fixed up the grammar, but I also don't know much about shells and may have made an incorrect assumption.
- This article still needs more sources. The Microsoft Knowledge Base may hold reliable sources for the Windows and DOS side of this article. man pages from die.net may help for the *NIX side of this article. — Preceding unsigned comment added by 126.96.36.199 (talk) 16:36, 3 March 2015 (UTC)
Edits - March 5, 2015
- "mistyped the first word > "typed an incorrect first word" (fluency)
- Recent > later (English connotations)
- "the Windows NT" - Windows NT is a family, and modern English does not need "the" prefixed
- Yes, MS-DOS spat out the same output for a missing file, since MS-DOS does not distinguish between system commands and files like *nix shells do. (Those who do not learn history are doomed to repeat it.)
- Mistyped command or unrecognized (nonexistent) command - MS-DOS has the same error for both situations.
- Like I've stated previously (albeit ambiguously), "because they searched for a file matching the command name and this is the stderror when a file is not found" is clunky English. Everything in *nix is a file, so shell commands were actually executables. ("due to a nonexistent file" covers both shell commands, *nix executables, and data files.) Obviously the < code > segment in the article is the output, so saying it again is redundant. If the file is nonexistent, it's obvious that the shell searched for it, so "they searched for a file matching the command name" is redundant.
- Even though the article gets shorter with my edits, it becomes more concise and less redundant. There's really no use to having unnecessary sentences and phrases that state the same thing. — Preceding unsigned comment added by 188.8.131.52 (talk) 19:23, 5 March 2015 (UTC)
- "Incorrect first word" does sound better. Oops, misread that. I guess you disagree. It's probalbly ok to leave it as your version.
- It is not possible to list all systems that have altered the message, so the sentence is just trying to give some examples. Apparently the system called "Windows NT" was where the message was first changed, so it is better than trying to be more encompassing by using "family". Maybe mention whatever the first version of MSDOS to have it altered was, but I don't know that. I also think "later" is more accurate than "recent" considering a lot of readers of Wikipedia are younger than this change.
- The unix message is from a c library function called "strerror". I think you are reading it as "stderror" which is the name of the stream it is written on. You may be right that there is no need to mention the exact source of the text.
- Both Windows and Unix do pretty much the same thing with a command: the shell checks if it is a built-in command, then searches the path for an executable with that name. The main difference is the list of built-in commands is typically much smaller in a Unix shell, and often there is a backup executable to do the same thing. In any case they both have the same information about what went wrong, and both produced equally cryptic messages, and both decided to fix the messages.
- I don't like that you expanded the explanation of "foo" to be "the incorrect file or command name". You are making the same mistake the writers of the error message did in being technically correct but confusing.
- Spitzak (talk) 05:39, 6 March 2015 (UTC)
- Chiming in:
- The Windows 10 article mentions Windows 10 as "part of the Windows NT family . . . ". Other Wikipedia articles mention the whole family as "Windows NT family" or "Windows NT series" as well, probably because there are multiple OpSys's called "Windows NT." Also, stating the whole family of operating systems lets readers know that the changes last until today.
- OS/2 should be included as an example because it's (chronologically) close to DOS and shows where the change started. (Someone else should probably be consulted to see what makes sense.)
- "mistyped first word" drops factual accuracy. Readers skimming the article without background knowledge in how shells work may be led to believe that shells accept English (or similar). If "mistyped first word" must be kept, please use "first mistyped word" instead.
- The rest of the article looks fine to me. 184.108.40.206 (talk) 05:29, 8 March 2015 (UTC)
- I take that back: This article needs an overhaul.
- General altered wording: More professional, less blog-like and choppy. (I'm not sure how to describe it -- the tone was a bit childish.)
- OS/2: I don't think we'll ever find a source for this because nobody's going to post a copyrighted screenshot of OS/2 or eComStation, and I'm sure the source and documentation for OS/2 and eComStation will never exist. (Though I do have a beta of it, so if someone wants to risk a lawsuit, I could probably gen some screenshots ;)
- Crappy referencing and crappy formatting: I'm sorry; I'm not good at editing Wikipedia articles. Call me a noob. The <ref> were cp'd from Windows XP. (Nor am I good at editing talk pages; I skimmmed the WP talk page documentation rather quickly.)
- Removed note 2: Note 2 isn't relevant for "early Unix shells" because it's "current".
- Source 1: I can't verify that. (I don't own the text nor have access to it.)
- Source 2: MSDN; I'm not sure what to put for the title.
- Source 3: The KB art's not specifically written to be focused on this topic but provides the main 3 error messages that can be triggered in Command Prompt. If you don't believe me, try it out for yourself.
- Source 4: Source archives. I hope the people looking at the citations know how to read C ;) There is no documentation for this message because the GNU community does not hold users by their hands and document every last function. The authors assume the message is self-explanatory and, if required, can be referenced in the source. The source for bash is the only reliable reference you'll ever find for this.
- Souce 5: Source archives. Same as Source #4 explanation. tcsh/csh is pretty popular among hardcore *nix fans, so I included it as a reference. I'm trying to keep the number of sources for that last sentence short, perhaps 3-4 at most to cover "most modern shells", but bash cannot be representative for "most modern shells" (nor will this be okay unsourced). 220.127.116.11 (talk) 08:02, 8 March 2015 (UTC)
- There seems to have been some confusion. There is only one error here, which is an incorrect first word of the line. Errors in later words of the commands always produced different error messages and thus are irrelevant for this article, except for the fact that users confused this message with other errors. I tried to restore the interesting information that this is an excellent example of a perfectly accurate error message that still manages to mislead users, and fix the Unix example where your "three types of errors" nonsense somehow leaked in. Please do not edit this again without explaining in detail, with examples, how mistyping the first word of a line either can produce a different error, or that mistyping a later word can produce "Bad command or file name".Spitzak (talk) 21:46, 16 March 2015 (UTC)
- Windows NT was an official produce from Microsoft and it produced the message shown. It is not clear if every single member of "The Windows NT family" produces this error, besides that text also kind of dates the fix to a lot later than it really happened.
Edits 17 March 2015
- "Microsoft's MS-DOS": PIN number, ATM machine, LCD display, PDF format, RAS syndrome, etc. Other Wikipedia articles seem to use "Microsoft's MS-DOS" anyway. I've posted something onto MS-DOS's Talk and am awaiting a reply.
- The source that says "The name specified . . . " -- I made a mistake; it appears Microsoft doesn't document error messages like that. Since cmd.exe resides within Windows 7 (the easiest copy of Windows to download b/c it doesn't require an installer like 8 does), I'm tempted to cite the ISOs from the digitalrivercontent domain (with the reasoning that PDFs are cited for the text within them) to get a primary source in. But for now, I'll stick with a secondary source: a how-to guide.
foois the first word of the command)" - conflicts w/ Spitzak on 6 Mar 2015
- The UNIX paragraph needs more sources. Just because tclsh is cited does not indicate other shells have similar messages. bash and tcsh/csh are currently what the majority of OS X and Linux users use, so citing them helps cover "most modern shells" without citing 4 or 5 shells. --Actually, I'm removing the last part of the last sentence until an actual source for tclsh can be cited.
- TODO: Dump some of the second paragraph into the first paragraph to intro the topic better.
- @Spitzak: Windows NT is still ambig. on the version when this message was changed; do you have a source that can be cited?
- @Spitzak: Please watch out for sentence fragments; commas don't join sentences.
- @Spitzak: "attempt to obfuscate" and "whitewashing" - Please assume good faith. Not everyone vandalizes Wikipedia for fun.
- @Spitzak: "Bad command or file name" is both ambiguous and misleading. It has a double meaning and gives (the user) the wrong impression. The connotations of ambing. and misleading are about the same. However, I used "clarity" instead to say that the wording was changed to avoid double meanings and that the message wasn't just changed because Microsoft could change it (which goes for a lot of features).
- I certainly remember Unix doing this but I'm not sure how long ago. It happens if the shell blindly calls perror after not finding the command, since the most likely last failed system call was an attempt to open the file. Tclsh certainly does it still for the "exec" command. I thought it was interesting that the same mistake as MSDOS did was done years earlier in Unix shells.
- I am basing the "Windows NT" on previous text in this page, I have no citations for it. It may be easier to locate the first version of normal Windows that had command.com altered to produce a different error.
- I thought it was obvious from the previous text why they changed the message, but, whatever.
- Generally looks good now, with a small type I'm going to fix now.Spitzak (talk) 04:03, 18 March 2015 (UTC)