Talk:Core utilities

From ArchWiki
(Redirected from Talk:Tar)
Jump to: navigation, search


Looks like ln is missing. It would be useful as reference for symlink, allowing to remove various explicit $ ln -s ... from articles. –– nl6720talk 16:53, 19 May 2016 (UTC)

It could be added, yes. Problem I see with crosslinking is that it is not easy to construct a sentence around it, because the target is the first argument. For example, try to crosslink ln -s /dev/null /etc/pacman.d/hooks/70-dkms-install.hook ..
"To disable the 70-dkms-install.hook hook, symlink its name from /etc/pacman.d/hooks/ to /dev/null." - works but is complicated. --Indigo (talk) 17:24, 19 May 2016 (UTC)
You could instead use cp -s foo bar, which creates a symbolic link bar to the first argument foo. At least I wish I'd have known about this earlier, rather than be confused every time on what's the link, and what the target, with ln. -- Alad (talk) 17:38, 19 May 2016 (UTC)
I don't know, a new section can indeed be useful to mention the counterintuitive syntax and the smart cp -s alternative, but about replacing symlink instructions with verbose instructions I tend to be against: compared to the more famous similar cases, I've always totally supported Help:Style#Package management instructions because it allows to easily link to packages and make sure that users are aware of all the package management best practices, but for example since the switch to systemd (with the short rc.d transition), I've always found it slightly hard to systematically enforce Help:Style#systemd units operations, which — I have to be honest — exists only as an adaptation of the older rule that was used to describe the more complex initscripts method to enable/disable daemons. Introducing a new similar rule for symlinks would feel even less natural to me, IMHO reducing the readability of articles. — Kynikos (talk) 05:07, 21 May 2016 (UTC)
I don't see how cp is better: cp -s foo bar does exactly the same as ln -s foo bar. Both tools have the -t flag to potentially swap the order of arguments.
I agree with Kynikos: there are no gotchas to be described, so the explicit command is as clear and brief as it can be. As for Help:Style#systemd units operations, I believe one of its points is to provide a choice between starting and enabling units, which is very cumbersome to describe with explicit code blocks.
-- Lahwaacz (talk) 11:22, 21 May 2016 (UTC)
You can read the cp -s as "Copy foo symbolically to bar", 'copy' is more known/associated with the action and, thereby, intuitive than 'link' ("Link foo symbolically to bar"). --Indigo (talk) 12:42, 21 May 2016 (UTC)


About disclaimer "This article or section is a candidate for merging with Disk cloning".

dd(1) is not a Disc cloning utility. "dd - convert and copy a file". It is a core utility, has many purposes and better not move all that to Disk cloning. Better create a article for dd.

It can be used to:

  • Disc cloning is additional extensive use case. Which is mostly used nowadays.
  • {{ic|Get stream from device, dd /dev/random or some more input device.
  • Create load on CPU dd if=/dev/zero of=/dev/null.
  • Create load on disc dd if=/dev/zero of=/path/testfile bs=number_ofG count=times oflag=fdatasync.
  • Create I/O load on disk with many read/writes.
  • As a backup utility or part of solution.
  • Convert a file to upper/lower case.
  • And so on.

It has data stream control keys, like bs, count, oflag, what makes it more extensive utility for streams of data, than cp. - PiroXiline (talk) 15:51, 9 September 2016 (UTC)

I agree dd should stay as a subsection of this article; it is an important tool from the coreutils after all. What I am not sure about is that an article about it would be a better solution: the versatility of the tool and which options are useful may be better to describe in the context of what a user wants to achieve. So, disk cloning gives practical examples for that, USB flash installation media#Using dd similar with a special purpose, Securely wipe disk#dd others, etc. Merging such usecases/actions into an article about dd makes focus difficult, both for the article and the reader who wants to perform an action.
I think it would be better to simply add a few crosslinks to existing usage examples to the section, maybe as a bullet list like you do above. --Indigo (talk) 20:21, 9 September 2016 (UTC)
Removed a banner on moving dd to Disc Cloning.
Added link to Disc Cloning
Added info to page. Maybe it's not completely in perfect form, but informative. And can be incrementally improved, it's a wiki )) I think I return to it. - PiroXiline (talk) 15:33, 13 September 2016 (UTC)
As it stands, much of it is incomprehensible (for example, what does "But besides cp, dd can connect receive and wait bit input from devices" mean?), and listing every single feature of the tool is out of scope of this page which is about basic/introductory usage only. -- Alad (talk) 12:06, 13 September 2016 (UTC)
  • Yeah, I've checked "But besides cp, dd can connect receive and wait bit input from devices" is not true. cp can passthrough stream. I really long ago forgot about it.
  • The thing is, it is maybe not incomprehensible because both not explained and not referenced on ArchWiki in proper places. Like today "regular expression" is an term for old regular expression languages, not used anymore in most places. So using old term, 'regular expression', to new algorithms and languages is not proper. Coretools not using regular expression languaages. That is why appropriate term is 'pattern'. That's why today grep devs say "grep - prints lines that contain a match for a pattern" Full documentation. Because it print lines, it say it print lines. I wrote that prior.
What is incomprehensible here. Maybe it needs more polish. More links on proper words and explanation and reference of what is Unix philosophy, stdin, stdout, and stderr, pipe, in the first place.
  • dd make bit by bit copy of file/stream it receives, by default. Bit by bit mean identical, maybe properly say bit-to-bit. Combining flow control features, that is why it can used be used as disk tool. Ideally flow control also needs to be referenced. But that is why it mentioned, so people can google 'dd flow control'. And I reference full documentation and man.
I make good notes, so people can contribute over. Please don't hold back such a stuff so hard. As you point out, phrase about streams really was an error, I must have been check it. Thought there is nothing to check.
By the way, I casually propose, as a fun, look at man 1 dd. dd man is a old-classic example of incomprehensible language. That is why I wrote here is man, but read full documentation. - PiroXiline (talk) 16:13, 13 September 2016 (UTC)

Unix philosophy of core utilities

This is our minimal thanks to everyone before us and their and our history and also a core info that should be on ArchWiki.

I am shocked to completely realize, there is no any Unix philosophy information on ArchWiki.

  1. Reference on top that Core utilities have epic history and it is our (Arch Linux users) heritage. Utilites have basic ((Unix philosophy of core utilities| powerful principles)) and it is considered that Arch Linux or ArchWiki user at least aware of them. It is going to be explained in detail only here. And in allmost every ArchWiki article it going to be used, while considered you know major core utilites this principles.
  2. Unix philosophy of core utilities section
    1. Unix history
    2. Principles
      1. Unix philosophy (Unix-way)
        1. Do one thing
        2. stdin/stdout/stderr
          File utilities
          Text utilities
          Shell utilities
      2. Combinatorial nature of utilities
        Any utility designed and can be combined with each other in any possible for utility way.
        Which make them cornerstone of system architecture, simple and very powerfulCore Utilities.
    3. Add to table of utilities column Origin Where Written for Unix in 19.. also by ..'.
    4. We can just point it out to Wiki, but it's dishonourable for us.
  3. Then we can remove different utility derived/originally written/for Unix/Unix like everywhere. It's repeated all the time and needs to be combined. Not only GNU Core Utilities use described above, but really all that can be named Core Utilities in principle are Unix-way no way around that there, otherwise they are not versatile.
  4. Until utils are in this article they all can have same section about all and each one of them in a table. And some additional info in util subsection. And when some Utility grows in size, moves to full article. All this is going to be great to use, everything will be structured, crisp and ready. Reference this subsection here, and write a more util-specific details in article.
This kind of topic is completely out of scope for ArchWiki and should be described on Wikipedia, if anywhere. See w:Unix_philosophy. -- Alad (talk) 11:54, 13 September 2016 (UTC)
I'm not saying these all needs full-frontal copy-pasta explanation. - PiroXiline (talk) 15:31, 13 September 2016 (UTC)