Talk:Bash

From ArchWiki
Revision as of 23:21, 16 October 2011 by Aroko (Talk | contribs) (Extract script is not broken, however improve the note.)

Jump to: navigation, search

All About BASH?

Am I to understand that this are all there is about Arch's relationship with BASH? Where are the details of BASH-related files? Are there any configuration files associated with it? I've read things about it, but they don't seem to exist in Arch. Is that normal? Can anyone answer these questions? Thanks much. - KitchM 22:05, 30 March 2010 (EDT)


+1 KitchM I added an environment variables page here https://wiki.archlinux.org/index.php/Environment_Variables

Are you referring to variables which only apply to BASH? - KitchM 16:49, 29 May 2011 (EDT)

I believe the subject of environment variables are not necessarily exclusive to a particular shell or even OS. I did learn that syntax differs slightly between Linux shells. ie: export VARIABLE=value # is used for Bourne, bash, and related shells, whereas, setenv VARIABLE value # for csh and related shells. If you have additional knowledge on this subject to share, please do contribute... That being said, do you think it would be accurate to assume that anyone seeking info here, would 99+% of the time, be using Bash and Linux? - Jeff Story

What I'm trying to say is that there are already the mention of variables on this page, what is the significance of those to which you were referring? Thanks. - KitchM 02:53, 30 May 2011 (EDT)

OK I think we're having a communication issue on my part. I got to this discussion page via the "discussion" link here https://wiki.archlinux.org/index.php/Bash#Environment_variables which is the "Environment variables This article is a candidate for moving. It is suggested that this page or section be moved to Environment Variables. (Discuss)". So without carefully reading your comment above, and focusing on this, "Am I to understand that this are all there is" I added my "+1 KitchM" comment above. My reason for creating the Environment_Variables wiki page was motivated by there being very little on the subject available in the Arch wiki, and my lack of knowledge on the subject. To answer your question which I believe is asking what is the significance of Environment_Variables relating to your specific questions in your first comment here. Quick answer... none. What is the significance of supplying the Environment_Variables page to anyone who may not know about that subject.... Enough info to get a grasp on the subject and either be able to put it to use, or at least lead them in a direction to be able to further expand on researching and possible contributing further to the wiki. - Jeff Story

If there is to be a BASH article, any environmental variables which have to do with that should be included right there. They could also be included in the more general article about variables as well. This would give the two places the necessary info without needing to switch back and forth. However, a separate section in the environmental variables main article might also work as a link for reference from the other.
By the way, I learned that the use of colons does help in the continuity of these sorts of discussions. Perhaps that would work for you. Thanks for your good comments. - KitchM 18:10, 30 May 2011 (EDT)
I made an edit to Bash#Shell and environment variables attempting to provide a transition for the merge. --Emiralle 15:07, 29 September 2011 (EDT)

Merge?

There seems to be some question about a merge. I am not sure about any other facts surrounding such a suggestion, but here are my thoughts for what they're worth. I believe that the real standard should always be that susquent or related sujects be brought to the main (Bash), rather than taking away from Bash and putting something with Environmental Variables. Always combine the missing pieces with the main article. Divisions only create confusion and a break in mental flow. If there is some concern that an article gets too long (not a big deal IMHO), I would then try to figure a way to colapse part of it and hide it unless needed. This would always be the preferred method as it is the correct intuitive methodology. - KitchM 16:45, 29 September 2011 (EDT)

I disagree that Bash is the "main" article here. Environmental and shell variables are not specific to a particular shell. I say put Bash specific things in Bash and general things in a general article. You could possibly make a case arguing from Bash being the default Arch shell, but that is a different discussion. --Emiralle 17:28, 29 September 2011 (EDT)
Also, the scope of the article as stated in the summary is "Improving Bash over its default capabilities". If that is indeed the desired scope, I don't see a problem with keeping most of the specific examples in place and rewriting them with that emphasis (i.e. Improving default Bash (in Arch)). --Emiralle 17:43, 29 September 2011 (EDT)
Well, it would seem that Bash is indeed the main focus of the article, else the article would not be named "Bash". However, if the variables are generic in nature, then a separate article for them would seem correct and worth considering. In the same vein, would it be more appropriate to have one article for all shells, or is Bash so different? - KitchM 10:28, 30 September 2011 (EDT)
I was referring to the "improving default..." element of the stated scope, Bash is a given. I should have been more explicit about that. I think it would be fine to keep specific examples in Bash if the section talked more about what the defaults are for Bash in Arch and how to "improve" on them. Though "improving" is getting into subjective territory; subject for another discussion.
I don't know that much about alternate shells, but I think it would be best to keep them separate. The Bash and Zsh articles alone would be pain to merge and would result in a confusing read for some purposes. --Emiralle 13:32, 30 September 2011 (EDT)
Yes, keeping shell-specific articles separate is beyond dispute (they have different features, configuration... and they're independent from each other), while Environment Variables are a common subject, so they should stay in a proper article to avoid duplication of efforts. -- Kynikos 05:47, 1 October 2011 (EDT)

Come on guys you are discussing obvious thing for two weeks already. You should better produce new content instead of a lot of discussions. I see this section completely useless here, as 1)the variables are NOT bash specific and user of ALL shells should be aware of them; 2)nothing is discussed as how to improve bash; 3)environment variables are only listed. So I move them to the Environment Variables article. Done!

Please, this is not the kind of expressions we are used to read in discussion pages in the ArchWiki, I am warmly asking you to show more respect to the other users when replying in talk pages. I also remind you that you should always sign your edits in discussion pages (by appending ~~~~) and you should indent your answers one level deeper than the one you are replying to (by prepending colons to every line).
That said, I have asked you to explain better your recent edits to this article in your talk page, so that we can more easily understand and judge them.
Thank you. -- Kynikos 14:43, 12 October 2011 (EDT)

Invocation and config files

Right now the overview and sourcing order of config files is combined in a confusing way. I've tried to merge a redundant section called startup files from further down the page. Here is what I envision:

Bash#Configuration file overview
Give a description of what kind of things these config files can be used for.
Bash#Configuration file sourcing order
Explain how the different files are sourced.

I also think a Bash#Invocation section properly defining login vs interactive shells and legacy mode would be nice to have before these ideas are used.

I'm using the confusing manual, as I don't know much myself. If anyone who knows more is interested in helping this along I'd be much obliged. | Emiralle 03:10, 8 October 2011 (EDT)

Extract script is broken?

The existing extract script does not work for me - adding it to my .bashrc yields:

bash: /home/ryan/.bashrc: line 73: syntax error near unexpected token `('
bash: /home/ryan/.bashrc: line 73: `        *.t@(gz|lz|xz|b@(2|z?(2))|a@(z|r?(.@(Z|bz?(2)|gz|lzma|xz)))))'

Does anyone have a reason for this? If not, recommend replacing this script with the simpler:

function extract()      # Handy Extract Program.
{
    if [ -f $1 ] ; then
        case $1 in
            *.tar.bz2)   tar xvjf $1     ;;
            *.tar.gz)    tar xvzf $1     ;;
            *.bz2)       bunzip2 $1      ;;
            *.rar)       unrar x $1      ;;
            *.gz)        gunzip $1       ;;
            *.tar)       tar xvf $1      ;;
            *.tbz2)      tar xvjf $1     ;;
            *.tgz)       tar xvzf $1     ;;
            *.zip)       unzip $1        ;;
            *.Z)         uncompress $1   ;;
            *.7z)        7z x $1         ;;
            *)           echo "'$1' cannot be extracted via >extract<" ;;
        esac
    else
        echo "'$1' is not a valid file"
    fi
}

--Betarepeating 17:12, 15 October 2011 (EDT)

Hi, thanks for poking with this function. However everything works fine. You should carefully read the note below the function. It says: "Bash users should make sure extglob is enabled: shopt -s extglob." So apparently it wasn't enabled by your .bashrc before defining function extract. Also your script is not that general. Only one archive can be passed to it and its name cannot contain whitespace (and even more). If you continue using it by yourself enclose $1 in double quotes. Your script also does not return anything on whether the extract procedure was successful. Summarizing, function extract is fine and more general then yours. I'll improve the note, to make it more clear that extglob should be enabled. Aroko 19:21, 16 October 2011 (EDT)