Talk:Core utilities

From ArchWiki
Jump to: navigation, search

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)


mlocate

As of May 2017 the Arch mlocate package doesn't automatically enable the updatedb.timer script so the mention on this page is incorrect. Best (imo) would be to add an actual command line like "use # systemctl start updatedb.timer to start the daily update, and # systemctl enable updatedb.timer to persist this setting across reboots" to let users decide what to do.

—This unsigned comment is by Duanev (talk) 16:38, 2 June 2017‎. Please sign your posts with ~~~~!

The mlocate package version 0.26-6 contains the /usr/lib/systemd/system/multi-user.target.wants/updatedb.timer file, so the timer is enabled by default. -- Lahwaacz (talk) 17:32, 2 June 2017 (UTC)]
As mentioned the timer did not get enabled by default. Maybe this is a system wide change, but in any case the cgroups wiki page [1] is a great example, documenting how services can be enabled manually. —This unsigned comment is by Duanev (talk) 21:50, 5 June 2017‎. Please sign your posts with ~~~~!
Enabling a unit is not the same as starting, please read the systemd page. I've changed the wording to be more explicit, closing. -- Lahwaacz (talk) 06:29, 6 June 2017 (UTC)