I wanted to see how some variable was set so from the command line I typed 'set'. All kinds of code flashed before my eyes. I did 'set > 92_set.txt so I could see what is being displayed. The usual variables show up then... here is the last few variables and the start of the code: XMODIFIERS=@im=local XNLSPATH=/usr/X11R6/lib/X11/nls XSESSION_IS_UP=yes _=0 bash205='3.00.0(1)-release' bash205b='3.00.0(1)-release' bash3='3.00.0(1)-release' have=yes is=bash _ImageMagick () { local prev; prev=${COMP_WORDS[COMP_CWORD-1]}; case "$prev" in -channel) COMPREPLY=($( compgen -W 'Red Green Blue Opacity \ Matte Cyan Magenta Yellow Black' -- $cur )); return 0 ;; -colormap) COMPREPLY=($( compgen -W 'shared private' -- $cur )); return 0 ;; -colorspace) Looking through it, the code/script/whatever seems ImageMagick related and the entire output of set is just under 3900 lines. I did a 'switch user' from the kde menu and logged in using another user and got the same thing. I tried 'set' on my 9.1 box and got much the same, but different code: XMODIFIERS=@im=local XNLSPATH=/usr/X11R6/lib/X11/nls XSESSION_IS_UP=yes _= is=bash no_proxy=localhost _alias () { local cur; COMPREPLY=(); cur=${COMP_WORDS[$COMP_CWORD]}; case "$COMP_LINE" in *[^=]) COMPREPLY=($( compgen -A alias -S '=' -- $cur )) ;; *=) COMPREPLY=("$( alias ${cur%=} 2>/dev/null | sed -e 's|^alias '$cur'\(.*\)$|\1|' )") ;; esac } This one is just over 3000 lines. Any ideas as to what is going on and how to correct it? Doug
Doug, On Monday 03 January 2005 17:08, Doug B wrote:
I wanted to see how some variable was set so from the command line I typed 'set'. All kinds of code flashed before my eyes. I did 'set > 92_set.txt so I could see what is being displayed. The usual variables show up then... here is the last few variables and the start of the code:
The BASH "set" command displays shell procedures as well as all variables.
XMODIFIERS=@im=local XNLSPATH=/usr/X11R6/lib/X11/nls XSESSION_IS_UP=yes _=0 bash205='3.00.0(1)-release' bash205b='3.00.0(1)-release' bash3='3.00.0(1)-release'
Huh? I didn't even know there was a version 3.x BASH.
have=yes is=bash _ImageMagick () { ...
Looking through it, the code/script/whatever seems ImageMagick related and the entire output of set is just under 3900 lines. I did a 'switch user' from the kde menu and logged in using another user and got the same thing.
This fact combined with your unfamiliarity with the various shell procedures displayed suggest that these definitions originate in "/etc/bash.bashrc". (That's a 9.1 thing. I don't know if it's the same in 9.2, but it's a good bet. There's definitely no ImageMagick procedure in my system's /etc/bash.bashrc, though.)
I tried 'set' on my 9.1 box and got much the same, but different code:
XMODIFIERS=@im=local ...
This one is just over 3000 lines.
Any ideas as to what is going on and how to correct it?
What exactly do you think is wrong / broken? These shell procedures are defined, thus they're displayed by the "set" command. What's the problem?
Doug
Randall Schulz
On Monday 03 January 2005 07:31 pm, Randall R Schulz wrote:
What exactly do you think is wrong / broken? These shell procedures are defined, thus they're displayed by the "set" command. What's the problem?
The problem is unexpected behavior. Now that could well be because I expected the wrong thing. I haven't used 'set' in a very long time, but the last time I remember using it, all I saw was variables and their values. Doug
The Monday 2005-01-03 at 19:56 -0600, Doug B wrote:
The problem is unexpected behavior. Now that could well be because I expected the wrong thing. I haven't used 'set' in a very long time, but the last time I remember using it, all I saw was variables and their values.
Many of those things are defined in /etc/profile.d/complete.bash, which is loaded from /etc/bash.bashrc. Why? I don't know. -- Cheers, Carlos Robinson
On Monday 03 January 2005 09:16 pm, Carlos E. R. wrote:
The Monday 2005-01-03 at 19:56 -0600, Doug B wrote:
The problem is unexpected behavior. Now that could well be because I expected the wrong thing. I haven't used 'set' in a very long time, but the last time I remember using it, all I saw was variables and their values.
Many of those things are defined in /etc/profile.d/complete.bash, which is loaded from /etc/bash.bashrc. Why? I don't know.
Thanks Carlos, I have found where they are comming from. I installed bash completion. The /etc/bash/bashrc reads /etc/bash_completion which contains a lot of functions which are defined if you have a particular program installed. I guess I have not installed this until SuSE 9.1, so I never saw that kind of output from the set command. All I wanted to do was see the value of a certain variable and the current output was unexpected and it was not as easy to find what I wanted. Doug
On Monday 03 January 2005 11:19 pm, Doug B wrote:
Thanks Carlos,
I have found where they are comming from. I installed bash completion. The /etc/bash/bashrc reads /etc/bash_completion which contains a lot of functions which are defined if you have a particular program installed. I guess I have not installed this until SuSE 9.1, so I never saw that kind of output from the set command. All I wanted to do was see the value of a certain variable and the current output was unexpected and it was not as easy to find what I wanted.
Doug
Don't feel too badly about hating the set command. I've been wondering the same thing (why all the crap?) and have dug into it a few times. Seems a bit stupid to me too. Didn't use to be that way for me either but it has ever since 8.0 I think.
The Monday 2005-01-03 at 22:19 -0600, Doug B wrote:
Many of those things are defined in /etc/profile.d/complete.bash, which is loaded from /etc/bash.bashrc. Why? I don't know.
Thanks Carlos,
I have found where they are comming from. I installed bash completion. The /etc/bash/bashrc reads /etc/bash_completion which contains a lot of functions which are defined if you have a particular program installed.
I don't have bash-completion installed, but nevertheless, I do have a number of those functions, because they come with aaa_base.rpm. My environment has 411 lines - that's far from you four thousand :-) -- Cheers, Carlos Robinson
Wed, 05 Jan 2005, by robin1.listas@tiscali.es:
The Monday 2005-01-03 at 22:19 -0600, Doug B wrote:
Many of those things are defined in /etc/profile.d/complete.bash, which is loaded from /etc/bash.bashrc. Why? I don't know.
Thanks Carlos,
I have found where they are comming from. I installed bash completion. The /etc/bash/bashrc reads /etc/bash_completion which contains a lot of functions which are defined if you have a particular program installed.
I don't have bash-completion installed, but nevertheless, I do have a number of those functions, because they come with aaa_base.rpm. My environment has 411 lines - that's far from you four thousand :-)
$ set|wc -l 3743 Bash_Completion is a very handy thing to use. E.g. $ postconf q<tab><tab> qmgr_clog_warn_time qmqpd_timeout qmgr_fudge_factor queue_directory qmgr_message_active_limit queue_file_attribute_count_limit qmgr_message_recipient_limit queue_minfree qmgr_message_recipient_minimum queue_run_delay qmqpd_authorized_clients queue_service_name qmqpd_error_delay groups <tab><tab> amavis dovecot lp named privoxy stunnel [..] help <tab><tab> . cd enable hash printf source umask [..] etc. Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 9.2 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.8 + MSN: twe-msn@ferrets4me.xs4all.nl See headers for PGP/GPG info. +
The Wednesday 2005-01-05 at 23:01 +0100, Theo v. Werkhoven wrote:
Bash_Completion is a very handy thing to use. E.g. $ postconf q<tab><tab> qmgr_clog_warn_time qmqpd_timeout qmgr_fudge_factor queue_directory qmgr_message_active_limit queue_file_attribute_count_limit qmgr_message_recipient_limit queue_minfree qmgr_message_recipient_minimum queue_run_delay qmqpd_authorized_clients queue_service_name qmqpd_error_delay
groups <tab><tab> amavis dovecot lp named privoxy stunnel [..]
Gosh! Interesting! :-) -- Cheers, Carlos Robinson
A little more info On Monday 03 January 2005 07:31 pm, Randall R Schulz wrote:
Doug,
The BASH "set" command displays shell procedures as well as all variables.
from man set: set [--abefhkmnptuvxBCHP] [-o option] [arg ...] Without options, the name and value of each shell variable are displayed in a format that can be reused as input. The output is sorted according to the current locale. That is the output I expected.
bash205='3.00.0(1)-release' bash205b='3.00.0(1)-release' bash3='3.00.0(1)-release'
Huh? I didn't even know there was a version 3.x BASH.
~> bash --version GNU bash, version 3.00.0(1)-release (x86_64-suse-linux) Copyright (C) 2004 Free Software Foundation, Inc. I guess there are some things you don't know.
This fact combined with your unfamiliarity with the various shell procedures displayed suggest that these definitions originate in "/etc/bash.bashrc". (That's a 9.1 thing. I don't know if it's the same in 9.2, but it's a good bet. There's definitely no ImageMagick procedure in my system's /etc/bash.bashrc, though.)
~> ls -l /etc/bash* -rw-r--r-- 1 root root 5723 2004-10-01 06:31 /etc/bash.bashrc -rw-r--r-- 1 root root 150303 2004-10-01 21:04 /etc/bash_completion I believe those dates are prior to the release date and certainly prior to my install date. The ~/.bashrc files for each user are as of the user creation date. None of this have been modified on my 9.2 or 9.1 boxes.
What exactly do you think is wrong / broken? These shell procedures are defined, thus they're displayed by the "set" command. What's the problem?
Same as I said before... unexpected behavior. Doug
Doug, On Monday 03 January 2005 18:15, Doug B wrote:
A little more info
On Monday 03 January 2005 07:31 pm, Randall R Schulz wrote:
Doug,
The BASH "set" command displays shell procedures as well as all variables.
from man set: set [--abefhkmnptuvxBCHP] [-o option] [arg ...] Without options, the name and value of each shell variable are displayed in a format that can be reused as input. The output is sorted according to the current locale.
That is the output I expected.
Well, you got the output that was defined. I guess the problem is that you don't understand the definition of "shell variable" in this context.
bash205='3.00.0(1)-release' bash205b='3.00.0(1)-release' bash3='3.00.0(1)-release'
Huh? I didn't even know there was a version 3.x BASH.
~> bash --version GNU bash, version 3.00.0(1)-release (x86_64-suse-linux) Copyright (C) 2004 Free Software Foundation, Inc.
I guess there are some things you don't know.
That's gratuitous and rude. If I wanted to present an air omniscience, I would not have let on that I was unaware of the existence of version 3.x BASH.
This fact combined with your unfamiliarity with the various shell procedures displayed suggest that these definitions originate in "/etc/bash.bashrc". (That's a 9.1 thing. I don't know if it's the same in 9.2, but it's a good bet. There's definitely no ImageMagick procedure in my system's /etc/bash.bashrc, though.)
~> ls -l /etc/bash* -rw-r--r-- 1 root root 5723 2004-10-01 06:31 /etc/bash.bashrc -rw-r--r-- 1 root root 150303 2004-10-01 21:04 /etc/bash_completion
I believe those dates are prior to the release date and certainly prior to my install date. The ~/.bashrc files for each user are as of the user creation date. None of this have been modified on my 9.2 or 9.1 boxes.
Are the unfamiliar shell procedures defined there? If so, what does it matter what the modification times are on the files? As far as that goes, mod times can be changed with system calls--they're not any kind of definitive indication of when the file was actually written. Have you actually found the source of the unexpected definitions? If not, use the recursive search option to egrep to find them.
What exactly do you think is wrong / broken? These shell procedures are defined, thus they're displayed by the "set" command. What's the problem?
Same as I said before... unexpected behavior.
And? Is there actually a problem? Is something actually malfunctioning? If not, what's the deal? What do you want?
Doug
Randall Schulz
On Monday 03 January 2005 09:31 pm, Randall R Schulz wrote:
I guess there are some things you don't know.
That's gratuitous and rude.
You are right. Your first response hit me wrong. It came across to me as cold and condescending. Anyway, that doesn't mean I should react in a negative way. Doug
Randall R Schulz wrote:
Doug,
On Monday 03 January 2005 18:15, Doug B wrote:
A little more info
On Monday 03 January 2005 07:31 pm, Randall R Schulz wrote:
Doug,
The BASH "set" command displays shell procedures as well as all variables.
from man set: set [--abefhkmnptuvxBCHP] [-o option] [arg ...] Without options, the name and value of each shell variable are displayed in a format that can be reused as input. The output is sorted according to the current locale.
That is the output I expected.
Well, you got the output that was defined. I guess the problem is that you don't understand the definition of "shell variable" in this context.
My, you're touchy today... This is a great opportunity to once again promote the info-system ;-) After some short search you find the more appropriate " This builtin is so complicated that it deserves its own section. `set' set [--abefhkmnptuvxBCHP] [-o OPTION] [ARGUMENT ...] If no options or arguments are supplied, `set' displays the names and values of all shell variables _and_ _functions_, sorted according to the current locale, in a format that may be reused as input. ..." <snip>
What exactly do you think is wrong / broken? These shell procedures are defined, thus they're displayed by the "set" command. What's the problem?
Same as I said before... unexpected behavior.
And? Is there actually a problem? Is something actually malfunctioning? If not, what's the deal? What do you want?
You're right but not very nice about it. I was very surprised, too, when it first happened to me. I came from RedHat and SuSE simply makes much more usage of functions. You don't see those in (old) RH-systems.
Doug
Randall Schulz
Kolja
participants (6)
-
Bruce Marshall
-
Carlos E. R.
-
Doug B
-
Kolja Kauder
-
Randall R Schulz
-
Theo v. Werkhoven