11–20 of 53 posts
Earlier quoted context omitted.
That's under Linux (not sure if that man page is maintained by glibc or the kernel seeing as it is a syscall). That's pretty different under a system that cares : http://man.openbsd.org/OpenBSD-current/man2/write.2
I'm sorry, how is it different than the linux example? They both describe all the parameters in the first sentence of the description.
Wow, a man page that is actually readable and understandable. I've been using Linux for years, and never once have I seriously looked at a man page. One of the more useless pieces of advice Linux beginners are given is to `man [tool]`. The documentation often has tonnes of useless information and no examples. It's frustrating, and it's also why projects like tldr[0] have gotten so popular. But, the page linked in the…
One place where the MSDN docs is way ahead of the manpages is the documentation of function paramters. For instance, here's the ouput of man 2 write . ssize_t write(int fd, const void *buf, size_t count); DESCRIPTION write() writes up to count bytes from the buffer pointed buf to the file referred to by the file descriptor fd. The number of bytes written may be less than count if, for example, there is insufficient s…
Wow, a man page that is actually readable and understandable. I've been using Linux for years, and never once have I seriously looked at a man page. One of the more useless pieces of advice Linux beginners are given is to `man [tool]`. The documentation often has tonnes of useless information and no examples. It's frustrating, and it's also why projects like tldr[0] have gotten so popular. But, the page linked in the…
Wow, a man page that is actually readable and understandable. I've been using Linux for years, and never once have I seriously looked at a man page. One of the more useless pieces of advice Linux beginners are given is to `man [tool]`. The documentation often has tonnes of useless information and no examples. It's frustrating, and it's also why projects like tldr[0] have gotten so popular. But, the page linked in the…
You're such an idiot, my god. Maybe get yourself a brain and you'll understand all manpages :)
The mistake the community made is putting git on the throne of version control. It's not. It's a tool for experts that can do a lot for you if you know how to use it. But to achieve that it pays the price of not really being assessible.
Now that it's in its position, the best thing you can do is to learn it. There is the git book. Read it. Annoying, I know. But that's the gameplan. Not doing it is just dragging out the inevitable.
Wow, a man page that is actually readable and understandable. I've been using Linux for years, and never once have I seriously looked at a man page. One of the more useless pieces of advice Linux beginners are given is to `man [tool]`. The documentation often has tonnes of useless information and no examples. It's frustrating, and it's also why projects like tldr[0] have gotten so popular. But, the page linked in the…
man pages are quite useful as reference documents. Which is their intended purpose.
I thought of giving it a name like `tutor`. Where you can use it without arguments for a general shell tutorial and with arguments for a mini-tutorial about a command
$ tutor
Welcome to the Bash command shell. This is a short tutorial about how (and why) to use the shell...
$ tutor ls
Use `ls` to view files in the current directory or one you specify. Examples:
- ls
Lists current directory (excluding files starting with a ., these are "hidden files")
- ls -A
Lists current directory including hidden files ... ===
Something like that at least. I think one of the worst things about the shell is finding out about the functionality there actually is, so having something like that built in could be handy. Maybe you could also have it do something like `tutor copy file` and have it find and list commands that fit the description.
I've seen a dozen of those tools wishing to "simplify" git and they all fail my workflow, which is pretty common I guess, team git with central server and source control.
What I use:
git push with target
git fetch
git checkout
git cherry-pick
git reflog
git log, status, diff obviously.Earlier quoted context omitted.
man pages are quite useful as reference documents. Which is their intended purpose.
I have the idea of creating a tool which is more like a tutorial for commands rather than the reference that `man` is. Has anyone made something like that before? I thought of giving it a name like `tutor`. Where you can use it without arguments for a general shell tutorial and with arguments for a mini-tutorial about a command $ tutor Welcome to the Bash command shell. This is a short tutorial about how (and why) to…
I love that they try to make it assessible. But I disagree with that it would be an acceptable goal in git just to understand a subset of it. You need to understand nearly everything, even the internals. Only then it can really become useful to you. The mistake the community made is putting git on the throne of version control. It's not. It's a tool for experts that can do a lot for you if you know how to use it. But…
I think the same could be said about C. It should not be put on the throne of "programming language" - you need to actually read and understand what it does internally. (pointers etc) - it's not enough to learn some incantations.
So then let me ask: is there a room for x, where git:x::C:python (git is to x, as C is to Python).
People everywhere deserve to have x. Not just right-clicking a file in Dropbox or OS X for previous versions, but a full commandline and detailed history including commit messages, and many other aspects of git.
In a way this is completely orthogonal to your comment, just as Python is to C.
EDIT: I've thought more about it and I no longer agree. The "language" presented here is a subset of C/C++ - not everything is mentioned or taught: https://www.arduino.cc/en/Reference/HomePage
It is in fact exactly this type of simplified subset. Not even malloc and free are mentioned... So while what you wrote is true for this audience (HN) there is room to learn less or a subset.
I love that they try to make it assessible. But I disagree with that it would be an acceptable goal in git just to understand a subset of it. You need to understand nearly everything, even the internals. Only then it can really become useful to you. The mistake the community made is putting git on the throne of version control. It's not. It's a tool for experts that can do a lot for you if you know how to use it. But…
This is a very useful comment. I think the same could be said about C. It should not be put on the throne of "programming language" - you need to actually read and understand what it does internally. (pointers etc) - it's not enough to learn some incantations. So then let me ask: is there a room for x, where git:x::C:python (git is to x, as C is to Python). People everywhere deserve to have x. Not just right-clicking…