GeneralThis forum is for non-technical general discussion which can include both Linux and non-Linux topics. Have fun!
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.
Yes, some things in Windows are very nice. Personally, I'm a fanboi of the Off button. Definitely Windows best feature.
I like the empty recycle bin when it says something like "Really delete 471 items from recycle bin?" - that's much better than "Are you sure?" because if you thought you had only 1 item in it the new information surprises you into checking it.
But when listing nice feature in Windows they do run out fairly quickly.
Do you agree that diff was thought as a tools to ease patches?
Again.....
Code:
~$ man patch
~$ man diff
If you want to customize the output using diff and patch a short read here can help make one better than what EXE can do.
To create your own patch file learn it from here.
There is no way M$ can beat gnu/linux/*nix/bsd on matters like this one simple lipstick painting.
Distribution: Ubuntu 12.04 with KXStudio, MATE & Compiz
Posts: 46
Rep:
Quote:
Originally Posted by stf92
Still missing the main point. It has been thought as a tool to ease patches.
If you think this is true, then please look into the Unix development history: who knows, it might be mentioned somewhere. The thing is, does it matter? No! Whatever idea it was that went through the developer's head that led to this thing, it is a general purpose tool.
You're hung up on "patches." Might have been part of it. Certainly fits into the *nix development environment, but it finds differences for all purposes, not just patching.
There is no way M$ can beat gnu/linux/*nix/bsd on matters like this one simple lipstick painting.
Another example: In MS-DOS/Windows, a simple 'DIR /AD' lists the names of all directories in the current directory. Could you tell me how you do it in Linux? See how I am speaking of the most basic tool in an OS.
Both can easily be tweaked to list further subdirectories as well (remove or adjust '-L 1' from the first or '-maxdepth 1' from the second). How is this done in DOS? Say I specifically wanted to list three levels deep?
All you are doing is showing that you know the limited DOS commands better than the more powerful and complete Linux commands.
EDIT: Also how about these alternatives?
Code:
ls -al | grep ^d
Or using a command line completion trick
Code:
cd [TAB][TAB]
If you don't care about hidden directories this would also work
Code:
echo */
That is 5 different *nix commands that could all potentially give you this information and I have no doubt there are more if you spend a little while thinking about it.
P.S. You can remove the -a from the tree and ls examples as well if you have no interest in hidden directories.
Last edited by ruario; 01-02-2013 at 01:01 AM.
Reason: added more examples
Distribution: Ubuntu 12.04 with KXStudio, MATE & Compiz
Posts: 46
Rep:
Quote:
Originally Posted by stf92
Another example: In MS-DOS/Windows...
I think you are in the wrong forum, and would be happier elsewhere.
Is it possible that there is any operating system that does not have what some person perceives as a difficulty or a deficiency? It's even likely that some of those are going to be legitimate.
Try scripting in Windows/DOS. That's "basic," isn't it? Then try even the earliest /bin/sh facilities. No comparison. Which is why when someone put my first DOS PC in front of me, I said, "take it away: it doesn't do anything useful!"
Anyway, this seems as pointless as trying to persuade me to like aniseed. But hey, I'm not going to an aniseed forum to post about it
Do you agree that diff was thought as a tools to ease patches?
Quote:
Originally Posted by Thad E Ginataom
If you think this is true, then please look into the Unix development history
Thad is correct. In fact it couldn't have been written primarily for use with patch because diff pre-dates the patch command by more than ten years. I'll quote from the patch and diff articles on Wikipedia (and if you don't trust them look at the sources linked at the end of the respective articles):
Quote:
Originally Posted by wikipedia patch article
The original patch program was written by Larry Wall (who went on to create the Perl programming language) and posted to mod.sources (which later became comp.sources.unix) in May 1985.
Quote:
Originally Posted by wikipedia diff article
The diff utility was developed in the early 1970s on the Unix operating system which was emerging from Bell Labs in Murray Hill, New Jersey. The final version, first shipped with the 5th Edition of Unix in 1974, was entirely written by Douglas McIlroy.
Regarding your statement that:
Quote:
Originally Posted by stf92
It is not intended to provide information to humans, only to other programs (patches).
Quote:
Originally Posted by stf92
Diff output was not thought to be human readable much machine readable.
This is not true, diff is simply a tool for showing differences in files (just like your favoured FC.EXE) and hence has many potential uses. More from the Wikipedia article:
Quote:
Originally Posted by wikipedia diff article
In diff's early years, common uses included comparing changes in the source of software code and markup for technical documents, verifying program debugging output, comparing filesystem listings and analyzing computer assembly code.
Clearly it is not bound to the patch command, nor is it useless without it. Humans are expected to be able to read and understand its output.
Quote:
Originally Posted by stf92
You want to compare two text files and don't need to know anything about the program. The output speaks for itself.
The problem (if there is one) is that you prefer the default output of FC.EXE over diff but I wouldn't expect everyone to agree with you. I just found a Windows machine to have a quick check, and even with no options it is IMHO completely inferior to diff. I certainly found it harder to understand the output and hence differences for a moderately complex set of changes. I suspect you prefer it primarily because you are more used to it or simply because you encountered FC.EXE first. This often happens in all aspects of life. For instance, I speak English and some, limited Norwegian. I find English easier, not because it actually is easier but simply because it was my first language.
Also as others have pointed out, in addition to the various options that let you tweak diff's output there are a wide range of alternative utilities for viewing differences between files. You simply need to do more research.
Last edited by ruario; 01-02-2013 at 06:52 AM.
Reason: Added more quotes to the start; added final quote and changed my closing sentences.
Distribution: Ubuntu 12.04 with KXStudio, MATE & Compiz
Posts: 46
Rep:
Thad is correct accidentally! I had no idea they were so far separated in time and wouldn't even have guessed it. But I am sure that it is one of the many utilities that stand alone, and do not exist just because others do.
Actually, I am not a developer, and have only seldom used the "patch" command. However, as a systems manager responsible not only for systems as a whole, but also specifically for various data belonging to various programs, I have often used diff and sdiff so I can say that from my own couple of decades of experience.
Earlier, when speaking about how complex tools are built from basic unix tools, I mentioned FSlint. I thought it was written in shell scripts. I was either thinking of a different tool, or just maybe a different version: it seems to be python. Not correct there!
Both can easily be tweaked to list further subdirectories as well (remove or adjust '-L 1' from the first or '-maxdepth 1' from the second). How is this done in DOS? Say I specifically wanted to list three levels deep?
All you are doing is showing that you know the limited DOS commands better than the more powerful and complete Linux commands.
EDIT: Also how about these alternatives?
Code:
ls -al | grep ^d
Or using a command line completion trick
Code:
cd [TAB][TAB]
If you don't care about hidden directories this would also work
Code:
echo */
That is 5 different *nix commands that could all potentially give you this information and I have no doubt there are more if you spend a little while thinking about it.
P.S. You can remove the -a from the tree and ls examples as well if you have no interest in hidden directories.
I was speaking about ls, which is the command which should perform that simple task. In fact, there is a way, and it is
Code:
ls -d */
But I new very few people knew this. You would never guess it by reading the man page! But a simple 'DIR /S/AD' will give you all dirs to any depth.
I think you are in the wrong forum, and would be happier elsewhere.
Is it possible that there is any operating system that does not have what some person perceives as a difficulty or a deficiency? It's even likely that some of those are going to be legitimate.
Try scripting in Windows/DOS. That's "basic," isn't it? Then try even the earliest /bin/sh facilities. No comparison. Which is why when someone put my first DOS PC in front of me, I said, "take it away: it doesn't do anything useful!"
Anyway, this seems as pointless as trying to persuade me to like aniseed. But hey, I'm not going to an aniseed forum to post about it
Shell scripting in Unix-like OSs is an arcane language. Because processors are so fast nowadays, everything is done in interpreted languages. So, those scripting languages have end up trying to emulate C. If you want to do fancy, sophisticated things, write a good program and compile it.
I was speaking about ls, which is the command which should perform that simple task. In fact, there is a way, and it is
Code:
ls -d */
But I new very few people knew this. You would never guess it by reading the man page! But a simple 'DIR /S/AD' will give you all dirs to any depth.
F.Y.I. that is exactly the same as my final method the 'magic' is not being done by ls (which is why it is not an example in the man page) but rather by shell expansion. It would be a really odd example to list in the man page.
But shouldn't ls satisfy such an elementary need? On the other hand you can put 'ls -d1 */'. Or add any number of ls options. How do you do this with echo?
No, actually it doesn't has to. The point of Unix/Linux commands is that you can chain them together in the ways you want/need them. So if one tool (in this case the shell) does a job already there is absolutely no need to implement the same functionality again in a different tool (in this case ls). In fact, it is much more sane in this case to let the shell do the job, since this enables any tool to benefit from it, even if it is only a simple echo command.
I actually can't see your point here. So there is tool on DOS/Windows that has a function that you don't have in a tool on *NIX. So what? Use the functionality given to you by your shell or other tools. If you still want to have that specific functionality in that specific tool, no problem at all. It is open source, go ahead and implement it (try that with DOS).
But shouldn't ls satisfy such an elementary need? On the other hand you can put 'ls -d1 */'. Or add any number of ls options. How do you do this with echo?
The power of these commands is simply the */ part which is expanded by the shell to match any (non-hidden) file with a name ending with a forward slash and of course only directories will end with a slash. The reason you you would find no reference to this in the ls man page because it is not an ls feature. It is a shell expansion feature, so if it were to be listed as an example anywhere it would be in the expansion section of your shell's man page. Consider also that if you used a shell that did not expand * like this, the command would fail.
By the way the -d is needed in your example because otherwise you would get the contents of the directories, since that is what ls always does by default when you list a direct as an option.
In any case it isn't true that you can use any of the ls options. For example you cannot use -a to show hidden files because ls did not filter them out in the first place. The */ never matched them.
Therefore the 'correct' way to do this (if you really wanted to do it) would be to use either the tree or find examples. They are not dependent on the shell and hence you can continue to use all of their options.
Quote:
Originally Posted by stf92
a simple 'DIR /S/AD' will give you all dirs to any depth.
You forgot to answer my question. I'll therefore repeat it for you with highlighting
Quote:
Originally Posted by ruario
Both can easily be tweaked to list further subdirectories as well (remove or adjust '-L 1' from the first or '-maxdepth 1' from the second). How is this done in DOS? Say I specifically wanted to list three levels deep
With tree you could do this as follows
Code:
tree -adL 3
or with find
Code:
find . -maxdepth 3 -type d
Now can you do the same with DIR on Windows? Perhaps it is not so simple to do now, due to the limited options on Windows.
Last edited by ruario; 01-02-2013 at 12:53 PM.
Reason: I forgot to add highlighting
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.