LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > General
User Name
Password
General This forum is for non-technical general discussion which can include both Linux and non-Linux topics. Have fun!

Notices

Reply
 
Search this Thread
Old 12-31-2012, 07:47 AM   #16
linosaurusroot
Member
 
Registered: Oct 2012
Distribution: OpenSuSE,RHEL,Fedora,OpenBSD
Posts: 751
Blog Entries: 2

Rep: Reputation: 194Reputation: 194

Quote:
Originally Posted by Hangdog42 View Post
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.
 
Old 01-01-2013, 01:56 AM   #17
malekmustaq
Senior Member
 
Registered: Dec 2008
Location: /root
Distribution: Slackware & BSD
Posts: 1,206

Rep: Reputation: 230Reputation: 230Reputation: 230
Quote:
Originally Posted by stf92 View Post
Still missing the main point. It has been thought as a tool to ease patches.
Come, try:
Code:
man patch
CAUTION:
The output in the terminal is only human readable to humans who can read English ...

Last edited by malekmustaq; 01-01-2013 at 01:57 AM.
 
Old 01-01-2013, 02:09 AM   #18
malekmustaq
Senior Member
 
Registered: Dec 2008
Location: /root
Distribution: Slackware & BSD
Posts: 1,206

Rep: Reputation: 230Reputation: 230Reputation: 230
Quote:
Originally Posted by stf92 View Post
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.

Hope that helps.

Good luck.
 
Old 01-01-2013, 03:29 AM   #19
Thad E Ginataom
Member
 
Registered: Mar 2011
Distribution: Ubuntu 12.04 with KXStudio, MATE & Compiz
Posts: 46

Rep: Reputation: 7
Quote:
Originally Posted by stf92 View Post
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.

If you don't like it, use something else!
 
Old 01-01-2013, 10:09 PM   #20
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,087

Original Poster
Rep: Reputation: 45
Quote:
Originally Posted by malekmustaq View Post

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.
 
Old 01-02-2013, 12:09 AM   #21
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,806

Rep: Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810
Code:
tree -adL 1
or if you prefer

Code:
find . -maxdepth 1 -type d
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
 
Old 01-02-2013, 12:25 AM   #22
Thad E Ginataom
Member
 
Registered: Mar 2011
Distribution: Ubuntu 12.04 with KXStudio, MATE & Compiz
Posts: 46

Rep: Reputation: 7
Quote:
Originally Posted by stf92 View Post
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
 
Old 01-02-2013, 05:55 AM   #23
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,806

Rep: Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810
Quote:
Originally Posted by stf92 View Post
Do you agree that diff was thought as a tools to ease patches?
Quote:
Originally Posted by Thad E Ginataom View Post
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 View Post
It is not intended to provide information to humans, only to other programs (patches).
Quote:
Originally Posted by stf92 View Post
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 View Post
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.
 
Old 01-02-2013, 09:05 AM   #24
Thad E Ginataom
Member
 
Registered: Mar 2011
Distribution: Ubuntu 12.04 with KXStudio, MATE & Compiz
Posts: 46

Rep: Reputation: 7
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!
 
Old 01-02-2013, 09:49 AM   #25
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,087

Original Poster
Rep: Reputation: 45
Quote:
Originally Posted by ruario View Post
Code:
tree -adL 1
or if you prefer

Code:
find . -maxdepth 1 -type d
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.
 
Old 01-02-2013, 10:02 AM   #26
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,087

Original Poster
Rep: Reputation: 45
Quote:
Originally Posted by Thad E Ginataom View Post
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.
 
Old 01-02-2013, 10:42 AM   #27
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,806

Rep: Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810
Quote:
Originally Posted by stf92 View Post
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.
 
Old 01-02-2013, 11:40 AM   #28
stf92
Senior Member
 
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 3,087

Original Poster
Rep: Reputation: 45
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?

Last edited by stf92; 01-02-2013 at 11:46 AM.
 
Old 01-02-2013, 12:18 PM   #29
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Gentoo
Posts: 15,438
Blog Entries: 2

Rep: Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001Reputation: 4001
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).
 
Old 01-02-2013, 12:40 PM   #30
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,806

Rep: Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810Reputation: 810
Quote:
Originally Posted by stf92 View Post
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 View Post
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 View Post
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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Windows XP + GRUB not playing nice emuuu Linux - General 9 08-29-2009 08:31 PM
LXer: How Windows Can Save Itself: Three Things We Want to See in Windows 7 LXer Syndicated Linux News 0 09-29-2008 07:30 PM
How to have fonts as nice as in MS Windows? calande Linux - General 5 07-12-2006 01:20 AM
Some nice things JanDeMan Linux - Networking 2 04-17-2004 05:44 AM
Windows not playing nice.... absolute0net Linux - Networking 0 07-07-2003 08:03 AM


All times are GMT -5. The time now is 11:12 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration