Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Linux is more based towards your computer while Windows is more geared towards the user. Hence, Linux prefers using ASCII characters for what they really are. Each ASCII represents something totally different in Computer Language. However, DOS dumbs things down and it makes no difference. This way Humans can work with a non case sensitive terminal easier.
However you should ask your self.
Are you not smart enough to tell the difference between a Lower Case and an Upper Case?
If you are not smart enough you should stay away from terminal.
But if you can tell the difference then why make things more distorted between you and your computer?
Linux is more based towards your computer while Windows is more geared towards the user. Hence, Linux prefers using ASCII characters for what they really are. Each ASCII represents something totally different in Computer Language. However, DOS dumbs things down and it makes no difference. This way Humans can work with a non case sensitive terminal easier.
Gnu/Linux is geared to the user. Which Gnu/Linux a user chooses will dictate the need to understand case while in a shell. Meaning if the user selects a *buntu type then the access to the terminal will be limited and sometimes no need at all. Users will sometimes use a GUI editor and be shown the difference in the 'shift' key to get the desired ASCII representation. Same way with a Microsoft user for ASCII, a user will eventually learn the case sensitivity. Microsoft 'cmd' does not take advantage for using case.
Quote:
Originally Posted by Mercury305
However you should ask your self.
Are you not smart enough to tell the difference between a Lower Case and an Upper Case?
If you are not smart enough you should stay away from terminal.
I totally disagree with the above. Working within a 'shell' can be a life enhancing event for one to learn. A user can learn to use the shell and should not be biased by statements like yours.
Quote:
Originally Posted by Mercury305
But if you can tell the difference then why make things more distorted between you and your computer?
It makes no sense for me...
Apparently you do not understand the working advantages for a 'shell'. In fact the above statement makes no relative association to case when used within a 'shell' be it Gnu/Linux or Microsoft. Writing a 'shell' script in bash provides a uniqueness.
Also within a '.bat' file the case sensitivity can be used to highlight or direct what one is doing even if '.cmd' shell will take either. The use of case with DOS 'bat' files can be used to provide understandable code therefore trace ability for a user when viewing to understand what is going on.
searching for a text string within electronic text
Some computer languages are case-sensitive (Java, C++, C#, C,Verilog, [1]Ruby[2] and XML). Others are case-insensitive (i.e., not case-sensitive), such as most BASICs (an exception being BBC BASIC), Fortran, SQL[3] and Pascal. There are also languages, such as Haskell, Prolog and Go, in which the capitalization of an identifier encodes information about its semantics.
Case-insensitive operations are sometimes said to fold case, from the idea of folding the character code table so that upper- and lower-case letters coincide. The alternative smash case is more likely to be used by someone that considers this behaviour a misfeature or in cases wherein one case is actually permanently converted to the other.
In Unix filesystems, filenames are usually case-sensitive. Old Windows filesystems (VFAT, FAT32) are not case-sensitive (there cannot be a readme.txt and a Readme.txt in the same folder) but are case-preserving, i.e. remembering the case of the letters. The original FAT12 filesystem was case-insensitive.[4] Current Windows file systems, like NTFS, are case-sensitive, that is you can have a readme.txt and a Readme.txt in the same folder, however, Windows disallows you to create a second file differing only in case.[5].
Gnu/Linux is geared to the user. Which Gnu/Linux a user chooses will dictate the need to understand case while in a shell. Meaning if the user selects a *buntu type then the access to the terminal will be limited and sometimes no need at all. Users will sometimes use a GUI editor and be shown the difference in the 'shift' key to get the desired ASCII representation. Same way with a Microsoft user for ASCII, a user will eventually learn the case sensitivity. Microsoft 'cmd' does not take advantage for using case.
I totally disagree with the above. Working within a 'shell' can be a life enhancing event for one to learn. A user can learn to use the shell and should not be biased by statements like yours.
Apparently you do not understand the working advantages for a 'shell'. In fact the above statement makes no relative association to case when used within a 'shell' be it Gnu/Linux or Microsoft. Writing a 'shell' script in bash provides a uniqueness.
Also within a '.bat' file the case sensitivity can be used to highlight or direct what one is doing even if '.cmd' shell will take either. The use of case with DOS 'bat' files can be used to provide understandable code therefore trace ability for a user when viewing to understand what is going on.
I think you misunderstood or I did not explain what I tried to correctly. I used sarcasm in the end about "being smart enough to differentiate caps".
Ofcorse the terminal is very important to use. I would be a fool to deny that. I did not mean the BAT files in DOS but rather the DOS Command Line Shell in which case sensitivity does not exist from my experience. I personally don't like DOS I find it backwards and unlogical. Yes that includes the so called Logical disk drives as well using letters.
An interesting thread. I wonder though why the OS on a REAL computer (IBM Mainframe) is upper case only? At least that has been my experience with MVS. It gets really upset if you ftp a file from a PC to a pds and end up with a mixed case name. Or if you get some mixed case text in a jcl member. Of course everything is stored as EBSIDC but that is another story.
Strictly speaking, case sensitivity is a function of the file system. Traditionally, Unix/Linux systems use case-sensitivity ... but the original file system that was installed on my (Mach Darwin) OS/X machine was case-insensitive. I replaced it with another Apple-provided choice.
Windows operating systems accept multi-case file names but treat those names in a case-insensitive way. When a Windows-compatible filesystem driver is used, so does Linux.
And finally, the original "FAT" filesystem shifted EVERY.NAM TOEIGHTD.OT3 ANDUPPER.CAS ONLY.DAT. If you were to install such a monstrosity on Linux, "so would Linux." (It of course could not run with such a system as its sysres volume, but it could theoretically use it on a partition or virtual-disk.)
Going even farther ... IBM mainframes still use EBCDIC, not ASCII. Even so, the file system (and/or network file system) drivers are the ultimate source of all such decisions.
An interesting thread. I wonder though why the OS on a REAL computer (IBM Mainframe) is upper case only? At least that has been my experience with MVS. It gets really upset if you ftp a file from a PC to a pds and end up with a mixed case name. Or if you get some mixed case text in a jcl member. Of course everything is stored as EBSIDC but that is another story.
Ken
The reason that IBM mainframe operating systems (VM, MVS, TSO, IMS, etc) are all case insensitive is due to their history. In the early days of computing, the vast majority of computer input came from punched cards and their very limited format required the user to work in one case. BCD and later EBCDIC are primarily punched card definitions which is why IBM mainframes are based on this standard.
These formats go back to the 1920s, well before electronic computing, when office data processing took place with information on punched cards and then large electromechanical sorters would sort the cards based on reading the punched holes. IBM rose to dominate all others in the computing field because it had a line of successful punched card systems and when electronic computers were introduced, they were careful to keep it compatible with existing equipment.
The 80 column punched card format became so persuasive that even today, many terminal emulators and of course a PC without graphics turned on all default to 80 characters/line.
... yes, and systems like Linux (and others) have to support "whatever comes."
The so-called file namespace, which is the set of allowable file-names, along with the matching-rules for determining whether a particular file's name matches the search-string given, is delegated to the file system driver. This also extends to, for example, whether or not a symbolic link is possible. Linux will match these resources to "inode numbers" for its own internal purposes, but it is specifically designed to be compatible with almost any file system (physical or network) that may come along.
Incidentally, so is Microsoft Windows. And, to a limited extent, so now is MVS (nee "z/OS"). In this way, the physical implementation of a "file system" resource is in effect abstracted away from the kernel itself. Installable driver modules are responsible not only for making the two-way connection to the resource, but also for making the "metadata" decisions (file names, directory structure, volume names) associated with that resource. "You can talk to it and use it, without specifically knowing or caring what it is or where it is, and you will be a well-behaved netizen who doesn't ask for it to do what it can't."
MVS really isn't an interactive operating system in the sense that most PC users are familiar with, so the paradigm of files is different. For that you would want to look at VM/CMS. VM has files of filename.type.disk. There is no concept of directories but "disk" works in a somewhat similar fashion. Interestingly VM/CMS can run guest operating systems including Linux. IBM has demonstrated a mainframe running 20,000 copies of Linux simultaneously and when a user logs onto one of those copies they are presented with the traditional linux upper/lower case filenames even thou the entire system is running in a VM.
MVS really isn't an interactive operating system in the sense that most PC users are familiar with, so the paradigm of files is different. For that you would want to look at VM/CMS. VM has files of filename.type.disk. There is no concept of directories but "disk" works in a somewhat similar fashion. Interestingly VM/CMS can run guest operating systems including Linux. IBM has demonstrated a mainframe running 20,000 copies of Linux simultaneously and when a user logs onto one of those copies they are presented with the traditional linux upper/lower case filenames even thou the entire system is running in a VM.
Yes, and when I worked at Amdahl many decades ago, we ran UTS (a Unix variant) on that class of hardware ... no VM, no MVS ... and wow!! could that hardware haul "*" when it didn't have to push MVS around anymore.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.