Difference between revisions of "Help talk:Reading"

From ArchWiki
Jump to: navigation, search
m (Revision criteria)
(Revision criteria: rm old discussion)
(6 intermediate revisions by 4 users not shown)
Line 6: Line 6:
 
Just like article:[[ABS]] is referred to in every page that involves compiling, this page could serve the same kind of utility.
 
Just like article:[[ABS]] is referred to in every page that involves compiling, this page could serve the same kind of utility.
  
==Revision criteria==
+
== Merge Common Shell files ==
sudo was removed because $ is already indicating that it should be ran as normal user, or ''should'' be indicating that in all articles. And it's not part of the core packages nor the intent of the article. [[User:Manolo|manolo]] 13:42, 12 November 2009 (EST)
+
 
+
:Sudo was added, to make it clear to the reader that sudo is something extra they need to install and configure in order to use it. If you search for sudo in the wiki you will see it is mentioned quite a bit. I'm fine whether it is included in this page or not. I did make it too verbose, maybe a short note should suffice. [[User:M l|M l]] 15:59, 12 November 2009 (EST)
+
 
+
----
+
 
Section [[Help:Reading#Common shell files]] should be merged with [[Bash]] and [[Zsh]]. [[User:Manolo|manolo]] 14:53, 13 November 2009 (EST)
 
Section [[Help:Reading#Common shell files]] should be merged with [[Bash]] and [[Zsh]]. [[User:Manolo|manolo]] 14:53, 13 November 2009 (EST)
  
 
: I think that 'Common shell files' should be in their respected pages. And remove any mention of common files. Is it not the purpose of this page to make the wiki in general easier to read and remove repetition? [[User:M l|M l]] 16:42, 13 November 2009 (EST)
 
: I think that 'Common shell files' should be in their respected pages. And remove any mention of common files. Is it not the purpose of this page to make the wiki in general easier to read and remove repetition? [[User:M l|M l]] 16:42, 13 November 2009 (EST)
 +
 +
::Yes, but the common files section is specific to Bash and Zsh. Repetition would still be avoided, articles could be:
 +
 +
:::Add to [[Bash#Configuration|Bash]] files:
 +
      # This alias makes ls colorize the listing
 +
      alias ls='ls --color=auto'
 +
 +
::Instead of what we have now:
 +
 +
:::Add the following using [[nano]], or [[vim]] to {{ic|~/.bashrc}} for personal settings, or {{ic|/etc/bash.bashrc}} for system-wide changes:
 +
      # This alias makes ls colorize the listing
 +
      alias ls='ls --color=auto'
 +
:::Don't forget to source the file in order to blahblah:
 +
      $ source /etc/bash.bashrc
 +
:::{{Tip|'source' can be abbreviated with '.' (a dot).}}
 +
 +
::Strictly speaking, $ and # differentiation is also specific to Bash, but for the sake of consistency every article should be using Bash-style denotation instead of "run as root" or "if using zsh, the root prompt will look different" etc. etc., so that excerpt belongs here. The same reasons apply with ''editing'' and ''sourcing''. Although I do see why somebody else would argue that it ''also'' belongs in [[Bash]].
 +
 +
::And the last section leads to other repetitive tasks that ''should not'' be repeated in every article. This is temporary, and once all editors conform to not including pacman and rc.conf tutorials in their docs, it'll be removed.
 +
 +
::I.e., this article is about interpreting the wiki (but will ''not'' include sections that belong in other articles). The new to GNU/Linux introduction part is a bit misleading.

Revision as of 17:02, 21 May 2013

Purpose

Besides covering basic differentiations, this article could serve to improve the quality of the Wiki by avoiding repetition. How many articles say: "edit in ~/.bashrc, or zhrc (if you're using zsh) -- alternatively, edit /etc/profile.bash for system-wide changes" or something to that effect? And even though it sounds counterintuitive, expanding this article makes the Wiki better for advanced users as well, since they won't be presented with the same old information they're accustomed to skip.

We could have a basic run down of common file locations and what they mean, instead of explaining them in every article. Editors can just say "add the following to the shell's configuration" and readers would then decide whether they want it system-wide or not, etc.

Just like article:ABS is referred to in every page that involves compiling, this page could serve the same kind of utility.

Merge Common Shell files

Section Help:Reading#Common shell files should be merged with Bash and Zsh. manolo 14:53, 13 November 2009 (EST)

I think that 'Common shell files' should be in their respected pages. And remove any mention of common files. Is it not the purpose of this page to make the wiki in general easier to read and remove repetition? M l 16:42, 13 November 2009 (EST)
Yes, but the common files section is specific to Bash and Zsh. Repetition would still be avoided, articles could be:
Add to Bash files:
      # This alias makes ls colorize the listing
      alias ls='ls --color=auto'
Instead of what we have now:
Add the following using nano, or vim to ~/.bashrc for personal settings, or /etc/bash.bashrc for system-wide changes:
      # This alias makes ls colorize the listing
      alias ls='ls --color=auto'
Don't forget to source the file in order to blahblah:
      $ source /etc/bash.bashrc
Tip: 'source' can be abbreviated with '.' (a dot).
Strictly speaking, $ and # differentiation is also specific to Bash, but for the sake of consistency every article should be using Bash-style denotation instead of "run as root" or "if using zsh, the root prompt will look different" etc. etc., so that excerpt belongs here. The same reasons apply with editing and sourcing. Although I do see why somebody else would argue that it also belongs in Bash.
And the last section leads to other repetitive tasks that should not be repeated in every article. This is temporary, and once all editors conform to not including pacman and rc.conf tutorials in their docs, it'll be removed.
I.e., this article is about interpreting the wiki (but will not include sections that belong in other articles). The new to GNU/Linux introduction part is a bit misleading.