Difference between revisions of "Talk:Core utilities"

From ArchWiki
Jump to: navigation, search
(Harmful aliases: update re)
(Added comment about clarifying function of commands within their titles)
Line 12: Line 12:
  
 
::::Yeah "Miscellaneous" is better. Categories only make sense when there's more than one thing in them and I think that some structure is better than none. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 13:09, 11 July 2018 (UTC)
 
::::Yeah "Miscellaneous" is better. Categories only make sense when there's more than one thing in them and I think that some structure is better than none. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 13:09, 11 July 2018 (UTC)
 
+
:::::Would it be possible to edit the titles for the commands? For example, in the table of contents just seeing "ls" isn't useful for a new person, but "ls - list files" would be. Maybe a very short description of function in each command name title would further help people find what they want to find in the article. [[User:Meskarune|Meskarune]] ([[User talk:Meskarune|talk]]) 19:55, 3 August 2018 (UTC)
 
== ln ==
 
== ln ==
  

Revision as of 19:55, 3 August 2018

Is it possible we could organize this article **not** in alphabetical order?

For new users seeing a list of random 2-3 letter words in the ToC is hardly useful. Maybe we could have sections instead such as "Directories" with things like mkdir and ls, "Permissions" with chown, chmod, and "View files" with head, tail, cat, pagers, etc This would make it much easier for someone to learn how to do something like create/delete/edit a file. It would also make it much easier for a person to look up a command they have forgot the name of. This document organizes the core utils by function: https://www.gnu.org/software/coreutils/manual/coreutils.html#touch-invocation so maybe we could so something like that but much simpler and focus on tools people would need to know to install and configure Arch initially. Meskarune (talk) 03:05, 13 March 2018 (UTC)

Past discussion: https://wiki.archlinux.org/index.php?title=Talk:Core_utilities&oldid=334765 -- Lahwaacz (talk) 07:18, 13 March 2018 (UTC)
I see, it sounds like they couldn't decide on groupings back then. I would propose just using the gnu groupings and only include the utils needed to install/configure and troubleshoot arch from the live CD. Keep the list some what small and then link to gnu's documentation. Meskarune (talk) 15:55, 5 April 2018 (UTC)
I agree that the utilities can be better organized. I propose to group the utilities and split Basic commands into File management, Text streams, System administration and Others. See User:Larivact/Core utilities. I also ordered utilities by importance and grouped related ones together. --Larivact (talk) 10:41, 10 June 2018 (UTC)
Request for comments. --Larivact (talk) 04:51, 11 July 2018 (UTC)
User:Larivact/Core utilities looks mostly good, except for the "Others". Ideally they should be properly categorized, but that might not be possible. How about naming the section "Miscellaneous" instead? Or maybe that would be even worse... -- nl6720 (talk) 12:34, 11 July 2018 (UTC)
Yeah "Miscellaneous" is better. Categories only make sense when there's more than one thing in them and I think that some structure is better than none. --Larivact (talk) 13:09, 11 July 2018 (UTC)
Would it be possible to edit the titles for the commands? For example, in the table of contents just seeing "ls" isn't useful for a new person, but "ls - list files" would be. Maybe a very short description of function in each command name title would further help people find what they want to find in the article. Meskarune (talk) 19:55, 3 August 2018 (UTC)

ln

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)

Harmful aliases

alias mkdir='mkdir -p -v'

You mostly don't need -p, if you use this alias and mistype a parent directory it creates a bunch of directories instead of failing.

alias mv='timeout 8 mv -iv'

This is a gem. If you use this alias and move a large file to another filesystem, timeout can terminate the move, resulting in an incomplete file without you noticing.

alias rm='timeout 3 rm -Iv --one-file-system'

And lastly all "security aliases" are dangerous because you get used to them, resulting in potential data loss when you use another system / user that doesn't have these aliases.

I think the uses of timeout should be removed and the danger of "security aliases" should be noted with Template:Warning.

--Larivact (talk) 10:32, 10 June 2018 (UTC)

I don't see why there should be any aliases in Core utilities, the additional command line options they add can be explained without aliasing the command. I'm for removing them all. -- nl6720 (talk) 11:51, 10 June 2018 (UTC)
I removed the timeout commands and added notes about "security aliases".--Larivact (talk) 07:11, 14 July 2018 (UTC)