[debian-user] thunderbird proxy env. vars for socks
Hi, I'm familiar with proxy envirnoment variables such as (both lower and upper case versions): use_proxy soap_use_proxy http_proxy https_proxy ftp_proxy rsync_proxy no_proxy all_proxy Thunderbird at least pay attention to some of them, and honestly, before I haven't needed anything else. However, inside the company, I need to setup manually under TB: SOCKS Host: <...> Port: <...> As SOCKS v5. Where the socks host is the same as the other proxy hosts, but its socks port must be different than the rest. I don't use any DE, but I have some automation through bash+xinitrc which depends on how to set the env. vars, so that I only need to set on TB/FF "use system proxy settings". I've tried several possible env. vars (both lower and upper case) like: socks_proxy socks_server socks_version smtp_proxy="socks5://:" So far I haven't been able to get any possitive results. Does any one know how I might be able to set socks for TB through env. vars? Thanks, -- Javier
Re: using `myscript.sh` to change current env
On Sat, Sep 07, 2013 at 04:35:09PM +1000, Zenaan Harkness wrote: I want to have a script, to change between a few prompts per the arg supplied. This is so I can quickly change from my glorious bells-and-whistles prompt to a plain prompt (eg for cut and paste to debian-user, just $ or # depending on current user) to a timestamped prompt (when I have some long-running process, and I want to see when it finished) etc. Not a direct solution to your problem, but zsh has a prompt command which will allow you to install a new prompt theme with a single command. For day-to-day work zsh is comparable to bash (the learning curve is much smaller than between e.g. bash and tcsh), but there's a lot of extra power available built-in. signature.asc Description: Digital signature
using `myscript.sh` to change current env
I want to have a script, to change between a few prompts per the arg supplied. This is so I can quickly change from my glorious bells-and-whistles prompt to a plain prompt (eg for cut and paste to debian-user, just $ or # depending on current user) to a timestamped prompt (when I have some long-running process, and I want to see when it finished) etc. In bash, we cannot run a script plainly, and have that script update the current shell's env. We could source the script with 'source' or '.' command, but this requires a correct location of the script to be entered, which is slow and not ideal. I want to be able to run the script as a command. So I thought, run the script in a subshell, executing the result, like: $ `ps1` The following 3-line script is meant to test exactly this: #!/bin/bash PS1=': ' echo export PS1=$PS1 Note that in this example, the desired new prompt is a colon followed by a single space. The problem is, when I run this script as `ps1`, I get a changed prompt, but just to colon, not including the space. Does anyone know how I might have a space character included in my new prompt, using this `way` to change my prompt? TIA Zenaan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOsGNSQhMnbEjBBecPYBiF4m20HZ6Av_fZE6EV=ofyaqfgd...@mail.gmail.com
Re: using `myscript.sh` to change current env
On 9/7/13, Zenaan Harkness z...@freedbms.net wrote:
So I thought, run the script in a subshell, executing the result, like:
$ `ps1`
The following 3-line script is meant to test exactly this:
#!/bin/bash
PS1=': '
echo export PS1=$PS1
When I change the last line to this:
echo export PS1=\${PS1}\
I get:
bash: export: `': not a valid identifier
So it appears that my current/parent shell is tokenizing the output of
`...` based on the space.
I guess, why is it tokenizing on space, yet ignoring the quotes?
TIA
Zenaan
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caosgnsrwo-culo3m9ipf5vhcevoixxetybx-ya0ujh-+awu...@mail.gmail.com
Re: using `myscript.sh` to change current env
Am 07. Sep, 2013 schwätzte Zenaan Harkness so:
moin moin Zenaan,
Rather than all the convolutions of command substitution, how about just
using a function that's in your profile or bashrc?
$ cat /tmp/bashrc
function changeps() {
export PS1=': '
}
$ . /tmp/bashrc
$ changeps
:
Add arguments to the fx() for your different options :).
ciao,
der.hans
I want to have a script, to change between a few prompts per the arg
supplied. This is so I can quickly change from my glorious
bells-and-whistles prompt to a plain prompt (eg for cut and paste to
debian-user, just $ or # depending on current user) to a
timestamped prompt (when I have some long-running process, and I want
to see when it finished) etc.
In bash, we cannot run a script plainly, and have that script update
the current shell's env.
We could source the script with 'source' or '.' command, but this
requires a correct location of the script to be entered, which is slow
and not ideal. I want to be able to run the script as a command.
So I thought, run the script in a subshell, executing the result, like:
$ `ps1`
The following 3-line script is meant to test exactly this:
#!/bin/bash
PS1=': '
echo export PS1=$PS1
Note that in this example, the desired new prompt is a colon followed
by a single space.
The problem is, when I run this script as `ps1`, I get a changed
prompt, but just to colon, not including the space.
Does anyone know how I might have a space character included in my new
prompt, using this `way` to change my prompt?
TIA
Zenaan
--
# http://www.LuftHans.com/http://www.LuftHans.com/Classes/
# Science is like sex: sometimes something useful comes out, but
# that is not the reason we are doing it. -- Richard Feynman
Re: using `myscript.sh` to change current env
On 9/7/13, Zenaan Harkness z...@freedbms.net wrote:
On 9/7/13, Zenaan Harkness z...@freedbms.net wrote:
So I thought, run the script in a subshell, executing the result, like:
$ `ps1`
The following 3-line script is meant to test exactly this:
#!/bin/bash
PS1=': '
echo export PS1=$PS1
After trying a few other options, it appears that the only simple
solution is to type a few extra chars:
PS1=`ps1`
where the ps1 script spits out the prompt content, not the command to
change the prompt. And that leads me to another potential solution,
see below.
This is reasonable given that all I want to do is embed my 'preferred
alternative prompts' in a script, so I can pass in a cmd line arg into
ps1 to pick a prompt on the fly, without having to go in and
cut-and-paste, or tediously locate the actual location of my ps1
script every time sourceing it.
Now, the alternate solution arises from the above, and from the
/etc/network/interfaces suggestion made yesterday by someone:
ps1 script can create itself a temporary file, and echo the command to
source that file. This might be solution solved ... exploring now ...
By the way, I've searched the net, from stackexchange to
comp.unix.shell, and have not yet found a solution to this seemingly
so simple problem.
Voila! It works!
My .bashrc used to have: source $BASHDIR/prompt
Now I just use `ps1` (after setting my path to include my bin/ dir
with the ps1 script of course).
And here it is, script ps1 to modify parent shell environment (by
running the script with command execution):
#!/bin/bash
# Bash script to change parent environment.
# Relies on storing the desired changes into a tmp file
# (see TMPFILE below),
# as well as on using command substitution when script is run.
# So therefore must be run as eg: `ps1`
GREEN_PROMPT='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]
\D{%Y%m%d} \t\[\033[00;36m\] \[\033[01;33m\]\w\[\033[00m\]\$ '
case $1 in
0) # simplest prompt (zero jazz):
case `whoami` in
root)
PS1='# '
;;
*)
PS1='\$ '
;;
esac
;;
t*)
# 't'imed - add date-time stamp to prompt:
case `whoami` in
root)
PS1='\D{%Y%m%d}-\t\# '
;;
*)
PS1='\D{%Y%m%d}-\t\$ '
;;
esac
;;
*)
# default: reset back to my preferred default prompt:
case `whoami` in
root)
PS1='\D{%Y%m%d}-\t\# '
;;
*)
case $TERM in
xterm* | rxvt* | linux | screen* | cygwin)
PS1=$GREEN_PROMPT
;;
*)
PS1='${debian_chroot:+($debian_chroot)}\u@\h:$(__git_ps1 %s):\w\$ '
;;
esac
;;
esac
;;
esac
TMPFILE=~/.`basename $0`.current-prompt
echo export PS1=\$PS1\ $TMPFILE
echo source $TMPFILE
Thanks for your assistance :)
Zenaan
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAOsGNSTSzDxZhEon7VTrKUgH1fj98cQO_Nkpte=4vn7knwz...@mail.gmail.com
Re: using `myscript.sh` to change current env
On 9/7/13, der.hans deb-u...@lufthans.com wrote:
Am 07. Sep, 2013 schwätzte Zenaan Harkness so:
moin moin Zenaan,
Rather than all the convolutions of command substitution, how about just
using a function that's in your profile or bashrc?
$ cat /tmp/bashrc
function changeps() {
export PS1=': '
}
$ . /tmp/bashrc
$ changeps
:
Add arguments to the fx() for your different options :).
Ahh. Even easier, and better (no tmpfile). Wunderbah!
Thank you. Appreciated,
Zenaan
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAOsGNSRLCCP5vuCL9g10La87yLyV=tggedcfpunahvi9fcv...@mail.gmail.com
Re: Re: using `myscript.sh` to change current env
Dear Zenaan,
I tried the same by putting those code in a script - myprompt.bash like below
#!/usr/bin/bash
PS1=': '
In terminal, when I run like '. ./myprompt.bash', it is working as expected.
Also I tried with alias like below and that also worked for me.
alias myprompt=export PS1=': '
Simply to run like 'myprompt'(without quotes) in terminal.
Regards,
Balamurugan R
On 09/07/2013 01:08 PM, Zenaan Harkness wrote:
On 9/7/13, der.hans deb-u...@lufthans.com wrote:
Am 07. Sep, 2013 schw�tzte Zenaan Harkness so:
moin moin Zenaan,
Rather than all the convolutions of command substitution, how about just
using a function that's in your profile or bashrc?
$ cat /tmp/bashrc
function changeps() {
export PS1= '
}
$ . /tmp/bashrc
$ changeps
:
Add arguments to the fx() for your different options :).
Ahh. Even easier, and better (no tmpfile). Wunderbah!
Thank you. Appreciated,
Zenaan
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/522be8ce.9010...@gmail.com
Mail in php by postfix in chroot env
Hello, I use php-fpm + nginx + mariadb on Debian wheezy x64 I decided to chroot php using build-in chroot feature. After changes in nginx vhost conf and php db conf (from localhost to IP for mysql) php and mysql works fine (I can connect to database, use phpmyadmin etc.), but I can't send emails. I use postifx and after read some articles I know that is because chroot. Tried to copy libs/postfix to chroot dir, but without results. Any ideas? Best regards, Lukasz
Re: Mail in php by postfix in chroot env
Łukasz Tkacz wrote: I use php-fpm + nginx + mariadb on Debian wheezy x64 I decided to chroot php using build-in chroot feature. After changes in nginx vhost conf and php db conf (from localhost to IP for mysql) php and mysql works fine (I can connect to database, use phpmyadmin etc.), but I can't send emails. What are you using to send email? How are you configured to send mail? Are you using SMTP? Or are you using /usr/sbin/sendmail? If the latter then your messages are queuing up in the chroot. Configure SMTP to 127.0.0.1 instead so that your Postfix daemon can handle it appropriately. By default I see that php uses SMTP to 127.0.0.1 so this should be working by default. What is in your php.ini file? [mail function] SMTP = localhost smtp_port = 25 ;sendmail_path = For the configuration options see: http://us2.php.net/manual/en/mail.configuration.php I use postifx and after read some articles I know that is because chroot. Tried to copy libs/postfix to chroot dir, but without results. Any ideas? Don't try to start postfix again in the chroot. You could. But it isn't optimal. I recommend against it. One Postfix install per machine is good. If you are using /usr/sbin/sendmail and want to continue such as in a general purpose then what I do is to install nullmailer in the chroot. The only trick is that you also need to install an init script to start it in the chroot at host system boot time. Bob signature.asc Description: Digital signature
Where to find setup for env variable?
Hi, I have setup somewhere the JAVA_HOME environment variable, but don't know where? $ env JAVA_HOME=/home/csanyipal/Programozas/JAVA/SunJava/jdk1.6.0_10 This was my previous setup for JAVA_HOME. I search in the following files for this setup: ~/.bash_profile ~/.bashrc ~/.gnomerc /etc/gdm/PostLogin/Default /etc/profile but find nothing. Now, in these files but not in '/etc/gdm/PostLogin/Default' I have setup JAVA_HOME: export JAVA_HOME=/usr/lib/jvm/java-6-openjdk export PATH=$PATH:/usr/lib/jvm/java-6-openjdk/jre/bin In the file '/etc/gdm/PostLogin/Default' I haven't setup JAVA_HOME. How can I find where is the setup that cause env to show the following? JAVA_HOME=/home/csanyipal/Programozas/JAVA/SunJava/jdk1.6.0_10 Any advices will be appreciated! -- Regards, Paul Chany You can freely correct me in my English. http://csanyi-pal.info -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxx62x0f@gmail.com
Re: Where to find setup for env variable?
On 2010-04-14, Paul Chany csanyi...@gmail.com wrote: Hi, I have setup somewhere the JAVA_HOME environment variable, but don't know where? ---SNIP--- Maybe /etc/environment? -- Liam O'Toole Birmingham, United Kingdom -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhsb3lh.bu7.liam.p.oto...@dipsy.selfip.org
Re: Where to find setup for env variable?
Liam O'Toole liam.p.oto...@gmail.com writes: On 2010-04-14, Paul Chany csanyi...@gmail.com wrote: I have setup somewhere the JAVA_HOME environment variable, but don't know where? ---SNIP--- Maybe /etc/environment? Here on my GNU/Linux Lenny system this file is empty. -- Regards, Paul Chany You can freely correct me in my English. http://csanyi-pal.info -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hbne2vqv@gmail.com
Re: Where to find setup for env variable?
Paul Chany: I have setup somewhere the JAVA_HOME environment variable, but don't know where? ~/.xsession? J. -- When driving at night I find the headlights of oncoming vehicles very attractive. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: Where to find setup for env variable?
Jochen Schulz m...@well-adjusted.de writes: Paul Chany: I have setup somewhere the JAVA_HOME environment variable, but don't know where? ~/.xsession? No. :( Maybe must I use grep to find the file containing 'JAVA_HOME'? If yes, I dont' know the exact expression of that grep command. -- Regards, Paul Chany You can freely correct me in my English. http://csanyi-pal.info -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3y22uy6@gmail.com
Re: Where to find setup for env variable?
On Wed, 14 Apr 2010 12:24:17 +0200, Paul Chany wrote:
Jochen Schulz writes:
Paul Chany:
I have setup somewhere the JAVA_HOME environment variable, but don't
know where?
~/.xsession?
No. :(
Maybe must I use grep to find the file containing 'JAVA_HOME'? If yes, I
dont' know the exact expression of that grep command.
I have saved a one-liner. You can try with:
***
find /* -type f -exec grep -H 'JAVA_HOME' {} \;
***
Be careful, as it will search inside all files under root /.
Greetings,
--
Camaleón
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/pan.2010.04.14.11.08...@gmail.com
Re: Where to find setup for env variable?
On 14.04.2010 12:24, Paul Chany wrote: Maybe must I use grep to find the file containing 'JAVA_HOME'? If yes, I dont' know the exact expression of that grep command. grep -sIr 'JAVA_HOME' /etc/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bc5a875@chello.at
Re: Where to find setup for env variable? [a question]
On 20100414_113944, Paul Chany wrote: Hi, I have setup somewhere the JAVA_HOME environment variable, but don't know where? ...snip When I am reading this thread there are already two search suggestions that are better than what I might have come up with. My post is to find out where the setting was actually done. I would have thought it could only be in /etc or /home --- but wierd things can happen. Where is it? How long did the search command take to run? And some idea of the size of your working environment? If the cause for that particular location appears to be something that involved user volition, it could still be useful to know what mistakes can be made. Better than learning from ones mistakes is learning from others experience. TIA -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100414141130.ga22...@big.lan.gnu
Re: Where to find setup for env variable?
Paul Chany wrote: Liam O'Toole liam.p.oto...@gmail.com writes: On 2010-04-14, Paul Chany csanyi...@gmail.com wrote: I have setup somewhere the JAVA_HOME environment variable, but don't know where? ---SNIP--- Maybe /etc/environment? Here on my GNU/Linux Lenny system this file is empty. -- Regards, Paul Chany You can freely correct me in my English. http://csanyi-pal.info Given that you have (presumably) installed some or all 'openjdk' packages, you could get a list of the installed files, per package, and see if any of the names listed point to anything of interest. Files in /etc, /etc/... (where ... might be 'openjdk'?), files in /lib or /usr/lib that are not library files, etc. could either be the source, or point to other files to check. This is a 'brute force' sort of technique, but it has helped me in a couple of cases where all else had failed. Bob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bc5f317.1020...@symantec.com
Re: Where to find setup for env variable? [a question]
Hi, Paul E Condon pecon...@mesanetworks.net writes: On 20100414_113944, Paul Chany wrote: I have setup somewhere the JAVA_HOME environment variable, but don't know where? When I am reading this thread there are already two search suggestions that are better than what I might have come up with. My post is to find out where the setting was actually done. I would have thought it could only be in /etc or /home --- but wierd things can happen. Where is it? How long did the search command take to run? And some idea of the size of your working environment? I find finally the setup of JAVA_HOME in /home/myusername/.profile file. Thank you all for help! -- Regards, Paul Chany You can freely correct me in my English. http://csanyi-pal.info -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq7ttlo6@gmail.com
Re: csh: how to use indirect ref to env vars
On Wed, 2008-06-25 at 08:03 -0700, ss11223 wrote:
On Jun 25, 9:40 am, michael [EMAIL PROTECTED] wrote:
Hi, I have acshscript in which I'd like to do set up a list of vars
and then to chk each of these are set, something like the below.
However, I can't find the magic incantation that allows to to check
${$Vars} eg if $InMetFiles is set on the first loop - suggestions
welcome!
#!/bin/csh
foreach Vars (InMetFiles InTerFile OutDir)
echo Checking $Vars\.\.\.
if ( ${?Vars} == 0) then
echo $Vars not set \- aborting
exit 1
endif
end
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
its ugly but I think this works
#!/bin/csh
foreach Vars (Var1 Var2 Var3)
echo checking $Vars\.\.\.
setenv temp '${'$Vars'}'
setenv temp2 `eval echo 'X'$temp /dev/null`
if ( $status != 0 ) then
echo $Vars not set \- aborting
exit 1
endif
end
it only works if csh is invoked without -e (stop on error)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
csh: how to use indirect ref to env vars
Hi, I have a csh script in which I'd like to do set up a list of vars
and then to chk each of these are set, something like the below.
However, I can't find the magic incantation that allows to to check
${$Vars} eg if $InMetFiles is set on the first loop - suggestions
welcome!
#!/bin/csh
foreach Vars (InMetFiles InTerFile OutDir)
echo Checking $Vars\.\.\.
if ( ${?Vars} == 0) then
echo $Vars not set \- aborting
exit 1
endif
end
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: csh: how to use indirect ref to env vars
michael wrote:
Hi, I have a csh script in which I'd like to do set up a list of vars
and then to chk each of these are set, something like the below.
However, I can't find the magic incantation that allows to to check
${$Vars} eg if $InMetFiles is set on the first loop - suggestions
welcome!
#!/bin/csh
foreach Vars (InMetFiles InTerFile OutDir)
echo Checking $Vars\.\.\.
if ( ${?Vars} == 0) then
echo $Vars not set \- aborting
exit 1
endif
end
maybe use (empty string) instead of 0 in the comparison.
HTH
Wackojacko
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: csh: how to use indirect ref to env vars
On Wed, 2008-06-25 at 15:02 +0100, Wackojacko wrote:
michael wrote:
Hi, I have a csh script in which I'd like to do set up a list of vars
and then to chk each of these are set, something like the below.
However, I can't find the magic incantation that allows to to check
${$Vars} eg if $InMetFiles is set on the first loop - suggestions
welcome!
#!/bin/csh
foreach Vars (InMetFiles InTerFile OutDir)
echo Checking $Vars\.\.\.
if ( ${?Vars} == 0) then
echo $Vars not set \- aborting
exit 1
endif
end
maybe use (empty string) instead of 0 in the comparison.
but I want to check that $InMetFiles is non-empty and then check
$InTerFile is non-empty, not that $Vars is non-empty...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: csh: how to use indirect ref to env vars
On Jun 25, 9:40 am, michael [EMAIL PROTECTED] wrote:
Hi, I have acshscript in which I'd like to do set up a list of vars
and then to chk each of these are set, something like the below.
However, I can't find the magic incantation that allows to to check
${$Vars} eg if $InMetFiles is set on the first loop - suggestions
welcome!
#!/bin/csh
foreach Vars (InMetFiles InTerFile OutDir)
echo Checking $Vars\.\.\.
if ( ${?Vars} == 0) then
echo $Vars not set \- aborting
exit 1
endif
end
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
its ugly but I think this works
#!/bin/csh
foreach Vars (Var1 Var2 Var3)
echo checking $Vars\.\.\.
setenv temp '${'$Vars'}'
setenv temp2 `eval echo 'X'$temp /dev/null`
if ( $status != 0 ) then
echo $Vars not set \- aborting
exit 1
endif
end
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: csh: how to use indirect ref to env vars
On Wed, 2008-06-25 at 08:03 -0700, ss11223 wrote:
On Jun 25, 9:40 am, michael [EMAIL PROTECTED] wrote:
Hi, I have acshscript in which I'd like to do set up a list of vars
and then to chk each of these are set, something like the below.
However, I can't find the magic incantation that allows to to check
${$Vars} eg if $InMetFiles is set on the first loop - suggestions
welcome!
#!/bin/csh
foreach Vars (InMetFiles InTerFile OutDir)
echo Checking $Vars\.\.\.
if ( ${?Vars} == 0) then
echo $Vars not set \- aborting
exit 1
endif
end
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
its ugly but I think this works
#!/bin/csh
foreach Vars (Var1 Var2 Var3)
echo checking $Vars\.\.\.
setenv temp '${'$Vars'}'
setenv temp2 `eval echo 'X'$temp /dev/null`
if ( $status != 0 ) then
echo $Vars not set \- aborting
exit 1
endif
end
ah, I see rather than testing a variable we try and use it and catch any
error... it seems to work as you say... although this seems slightly
more elegant if less easy to add new VarN to:
if ( $?InMetFiles == 0 || $?InTerFile == 0 {etc}) then
echo prob
exit -1
endif
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: csh: how to use indirect ref to env vars
On Jun 25, 12:40 pm, michael [EMAIL PROTECTED] wrote:
ah, I see rather than testing a variable we try and use it and catch any
error... it seems to work as you say... although this seems slightly
more elegant if less easy to add new VarN to:
if ( $?InMetFiles == 0 || $?InTerFile == 0 {etc}) then
echo prob
exit -1
endif
--
Not quite, see the section for eval in the csh man page. The idea
is to use
eval to re-evaluate the variable after the name substitution.
Here is a cleaner version of the concept:
#!/bin/csh
setenv Var1 3
foreach Vars (Var1 Var2 Var3)
echo checking $Vars\.\.\.
setenv temp '${?'$Vars'}'
eval setenv temp2 $temp
if ( $temp2 != 1 ) then
echo $Vars not set \- aborting
exit 1
endif
end
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
how to reset desktop env. config? (was: Re: What are these folders in home?)
Kamaraju S Kusumanchi wrote: paragasu wrote: AFAIK, you can delete all files in $HOME directory. especially the hidden files. the worst you will get is you lost some setting of the program. But you can login just fine. One has to be careful. For example, Kmail (from KDE) uses .kde to store all the mail. If some one deletes the .kde directory thinking that it is just a bunch of rc files they would be in for a nice surprise. raju I have encountered the soft reset situation many times: I wanted to start over with a particular desktop, KDE or Gnome. I usually do this: 1. log out from the window manager 2. kill all my files in /tmp 3. kill all relevant hidden directories in $HOME/ (e.g. .kde*, .gnome*, .gconf* and such). 4. Log in to the window manager. It starts configuration from scratch. Now, I do not use Kmail, just Thunderbird and mutt. I know where they save their email. And now I learn that kmail saves its data in .kde. I hope a user using Kmail knows this. But then, the question is, what is the right way to start over using a desktop environment above? Is there a soft reset for window managers and desktop env.? thanks, -HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to reset desktop env. config?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 H.S. wrote: Kamaraju S Kusumanchi wrote: paragasu wrote: AFAIK, you can delete all files in $HOME directory. especially the hidden files. the worst you will get is you lost some setting of the program. But you can login just fine. One has to be careful. For example, Kmail (from KDE) uses .kde to store all the mail. If some one deletes the .kde directory thinking that it is just a bunch of rc files they would be in for a nice surprise. raju I have encountered the soft reset situation many times: I wanted to start over with a particular desktop, KDE or Gnome. I usually do this: 1. log out from the window manager 2. kill all my files in /tmp 3. kill all relevant hidden directories in $HOME/ (e.g. .kde*, .gnome*, .gconf* and such). 4. Log in to the window manager. It starts configuration from scratch. Now, I do not use Kmail, just Thunderbird and mutt. I know where they save their email. And now I learn that kmail saves its data in .kde. I hope a user using Kmail knows this. But then, the question is, what is the right way to start over using a desktop environment above? Is there a soft reset for window managers and desktop env.? thanks, -HS Depends on the window manager, obviously, for example i use E, the various subdirectories of ~/.e are pretty obvious about what's in them, it doesn't take long to go through and hose just the right bits, and then you can restart E without even closing all your windows :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH8XoFLeTfO4yBSAcRAmljAJ91ofcjhp4CsDXHcOW0L+Qehf8RAACeKEgQ jSIQoxR9GjGPIisL2ug/SxE= =7sRH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to reset desktop env. config? (was: Re: What are these folders in home?)
H.S. wrote: But then, the question is, what is the right way to start over using a desktop environment above? Is there a soft reset for window managers and desktop env.? AFAIK, such a soft reset does not exist for KDE 3.5.5 users. It would be cool to have such a thing though. I gave the kmail as an example. The situation is similar even if you are using knode, korganizer etc., You loose the data along with configuration files when the .kde/ is deleted. hth raju -- Kamaraju S Kusumanchi http://www.people.cornell.edu/pages/kk288/ http://malayamaarutham.blogspot.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Env var on the fly
Having defined (in my .bashrc) the environmental variables for computing suites X and Y (PATH to them) it happens - because of some bug in X - that on running certain programs of Y, executables of X are called (and of course not found). If I undefine the env var X, all programs of Y run perfectly. Is any simple way to define the env var X on the fly, when X is needed, without having to use X as another user? (which would overcomplicate the matter because there is an scp link from the computing machine to and from a desktop, where I am). debian linux amd64 etch on the computing machine, where my .bashrc. deain linux i386 etch on the desktop. Thanks francesco pietra Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Env var on the fly
On Sat, Sep 29, 2007 at 08:23:59AM -0700, Francesco Pietra wrote: Having defined (in my .bashrc) the environmental variables for computing suites X and Y (PATH to them) it happens - because of some bug in X - that on running certain programs of Y, executables of X are called (and of course not found). If I undefine the env var X, all programs of Y run perfectly. Is any simple way to define the env var X on the fly, when X is needed, without having to use X as another user? (which would overcomplicate the matter because there is an scp link from the computing machine to and from a desktop, where I am). export X=blah or do you need it to happen automatically? in which case your application needs to do this. A signature.asc Description: Digital signature
Unterschied zwischen echo $PATH und env | grep $PATH
Hallo! Kann mir jemand erklären, worauf ein unterschiedliche Ergebnis der beiden Befehle beruhen kann? Anders gefragt: Wer verwendet die $PATH Variable, die von einem echo in einer normalen bash ausgegeben wird und wer verwendet env? MfG, Leonhard. PS: Mir geht es dabei insbesondere um dpkg da mein Problem (vgl. E-Mail debconf: apt-extracttemplates failed: Bad file descriptordpkg: dpkg - error: PATH is not set.) noch ungelöst ist.
Re: Unterschied zwischen echo $PATH und env | grep $PATH
Hallo, Mag. Leonhard Landrock wrote: Kann mir jemand erklären, worauf ein unterschiedliche Ergebnis der beiden Befehle beruhen kann? Variablen (bei Dir: PATH) können entweder nur für die aktuelle Shell gelten, oder aber exportiert werden, womit sie auch für Programme gesetzt sind, die über die Shell gestartet werden: [EMAIL PROTECTED]:~ $ FOO=bar [EMAIL PROTECTED]:~ $ echo $FOO bar [EMAIL PROTECTED]:~ $ env | grep FOO [EMAIL PROTECTED]:~ $ export FOO=bar [EMAIL PROTECTED]:~ $ env | grep FOO FOO=bar hth, Wolf -- Büroschimpfwort des Tages: Fallschirmspringer - Kollege, der in ein (eher informelles) Gespräch hineinplatzt, keine Sekunde abwartet und seinen Senf abgibt. (Thomas Schmidt-Hebbel) -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Unterschied zwischen echo $PATH und env | grep $PATH
Moin, * Mag. Leonhard Landrock wrote (2006-06-25 19:27): Kann mir jemand erklären, worauf ein unterschiedliche Ergebnis der beiden Befehle beruhen kann? Ist es denn unterschiedlich? Hast Du mal ein Beispiel? Wer verwendet die $PATH Variable, die von einem echo in einer normalen bash ausgegeben wird und wer verwendet env? Ich würde mich wundern, wenn ein Prozeß den Pfad ermittelt, indem er etwa im Output von env(1) 'rumgrept. Die Frage ist eher, warum $PATH unterhalb von env einen anderen Wert hat. Thorsten The Arcade Fire: Crown Of Love -- He that would make his own liberty secure, must guard even his enemy from oppression; for if he violates this duty, he establishes a precedent which will reach to himself. - Thomas Paine pgpkgYfFPROuy.pgp Description: PGP signature
Re: Unterschied zwischen echo $PATH und env | grep $PATH
Am Sonntag, 25. Juni 2006 19:32 schrieb Wolf Wiegand: Hallo, Mag. Leonhard Landrock wrote: Kann mir jemand erklären, worauf ein unterschiedliche Ergebnis der beiden Befehle beruhen kann? Variablen (bei Dir: PATH) können entweder nur für die aktuelle Shell gelten, oder aber exportiert werden, womit sie auch für Programme gesetzt sind, die über die Shell gestartet werden: [EMAIL PROTECTED]:~ $ FOO=bar [EMAIL PROTECTED]:~ $ echo $FOO bar [EMAIL PROTECTED]:~ $ env | grep FOO [EMAIL PROTECTED]:~ $ export FOO=bar [EMAIL PROTECTED]:~ $ env | grep FOO FOO=bar Danke, damit komme ich der Sache schon viel näher. Heißt das somit, dass env immer nur die Variablen liefert, die auch exportiert worden sind? Völlig offen ist für mich aber auch noch die Frage, wie den nun die normale Einstellung (d.h. nach einer kleinen Installation) für die PATH-Variable unter dem Konto root ist. Seit heute macht mir dpkg Probleme. Tatsächlich lieggt es offensichtlich an dem fehlenden Export der PATH-Variable. Frage: Sollte die PATH-Variable unter dem Konto root normalerweise exporteirt werden? Wenn ja, wo sollte das eingetragen sein? MFG, Leonhard.
Re: Unterschied zwischen echo $PATH und env | grep $PATH
Moin, * Wolf Wiegand wrote (2006-06-25 19:32): Variablen (bei Dir: PATH) können entweder nur für die aktuelle Shell gelten, oder aber exportiert werden, womit sie auch für Programme gesetzt sind, die über die Shell gestartet werden: Guter Gedanke. Da würde ich mal nach PATHs suchen, die geändert, aber nicht exportiert werden. [EMAIL PROTECTED]:~ $ export FOO=bar (Oder auch: 'export foo') Thorsten The Arcade Fire: No Cars Go -- Es gibt Dinge, für die es sich lohnt, eine kompromißlose Haltung einzunehmen. - Dietrich Bonhoeffer pgpORNalX3Pq2.pgp Description: PGP signature
Re: Unterschied zwischen echo $PATH und env | grep $PATH
Moin, * Mag. Leonhard Landrock wrote (2006-06-25 19:48): Heißt das somit, dass env immer nur die Variablen liefert, die auch exportiert worden sind? Plus die, die Du in env selbst änderst. Völlig offen ist für mich aber auch noch die Frage, wie den nun die normale Einstellung (d.h. nach einer kleinen Installation) für die PATH-Variable unter dem Konto root ist. Mit normal meinst Du wie von Debian gewünscht? Frage: Sollte die PATH-Variable unter dem Konto root normalerweise exporteirt werden? Wenn ja, wo sollte das eingetragen sein? Nein, wie alles andere solltest Du einen Export nur machen, wenn Du ihn brauchst. Ansonsten kannst Du den Befehl ja auch mit env starten und nur dort den Pfad ändern. Thorsten The Arcade Fire: Haiti -- Das Briefgeheimnis sowie das Post- und Fernmeldegeheimnis sind unverletzlich. - Grundgesetz, Artikel 10, Abs. 1 pgpPCvYwL0zkh.pgp Description: PGP signature
Re: Unterschied zwischen echo $PATH und env | grep $PATH
Hallo, Mag. Leonhard Landrock wrote: Heißt das somit, dass env immer nur die Variablen liefert, die auch exportiert worden sind? Eigentlich ist env dafür da, Programme zu starten und denen dabei eine andere Umgebung (geänderte Variablen) mitzugeben. Wenn env 'einfach so' gestartet wird, wird ausgegeben, welche Variablen für das zu startende Programm gültig wären (siehe man 1 env). Insofern: Ja, das, was env ausgibt, gilt auch für Programme, die Du in der Shell startest. Völlig offen ist für mich aber auch noch die Frage, wie den nun die normale Einstellung (d.h. nach einer kleinen Installation) für die PATH-Variable unter dem Konto root ist. Hier auf einer neuen Sarge-Installation: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin Frage: Sollte die PATH-Variable unter dem Konto root normalerweise exporteirt werden? Ja. Wenn ja, wo sollte das eingetragen sein? Ich würde jetzt sagen, /etc/profile (Auszug): if [ `id -u` -eq 0 ]; then PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 else PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games fi (Und hier komme ich ins Schwimmen, denn das stimmt nicht mit dem Überein, was das 'echo $PATH' weiter oben zurückgegeben hat.) Am besten selbst mal den Abschnitt 'INVOCATION' aus der manpage zu bash lesen. hth, Wolf -- Büroschimpfwort des Tages: Süßigkeitenkistenverwalter - weisen Kollegen darauf hin, dass sie schon zweimal an der Box mit den Süßigkeiten im Labor oder Büro waren. (Jan Topel) -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Unterschied zwischen echo $PATH und env | grep $PATH
Am Sonntag, 25. Juni 2006 20:03 schrieb Wolf Wiegand: Hallo, Mag. Leonhard Landrock wrote: Völlig offen ist für mich aber auch noch die Frage, wie den nun die normale Einstellung (d.h. nach einer kleinen Installation) für die PATH-Variable unter dem Konto root ist. Hier auf einer neuen Sarge-Installation: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/ bin Frage: Sollte die PATH-Variable unter dem Konto root normalerweise exporteirt werden? Ja. Wenn ja, wo sollte das eingetragen sein? Ich würde jetzt sagen, /etc/profile (Auszug): if [ `id -u` -eq 0 ]; then PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin /X11 else PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games fi (Und hier komme ich ins Schwimmen, denn das stimmt nicht mit dem Überein, was das 'echo $PATH' weiter oben zurückgegeben hat.) Am besten selbst mal den Abschnitt 'INVOCATION' aus der manpage zu bash lesen. hth, Wolf Auszug aus der bash man-page: When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior. Meine /etc/profile Datei: # /etc/profile: system-wide .profile file for the Bourne shell (sh(1)) # and Bourne compatible shells (bash(1), ksh(1), ash(1), ...). if [ `id -u` -eq 0 ]; then PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 else PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games fi if [ $PS1 ]; then if [ $BASH ]; then PS1='[EMAIL PROTECTED]:\w\$ ' else if [ `id -u` -eq 0 ]; then PS1='# ' else PS1='$ ' fi fi fi export PATH umask 022 Auszug aus meiner ~/.bash_profile für den Benutzer root: Nein! Das kann ich hier nicht posten. ;-) OK, jetzt weiß ich wo der Hund begraben liegt. Ein fehlgeschlagenes Linux from Scratch experimentieren. Meine ~/.bash_profile ist gelinde gesagt Schrott. :-) Der Tipp Am besten selbst mal den Abschnitt 'INVOCATION' aus der manpage zu bash lesen. war Gold wert. Danke und lG, Leonhard.
Too many env vars in an automated PXE/preseed Debian installation
Hello :) I am trying to automate Debian installation in a Dell PowerEdge server via PXE-boot and preseeding files. I want to automatically select language, country, keyboard layout, etc.. and pass preseed file, those are the kernel parameters that are appending via pxelinux boot: -- label sarge-amd64 kernel deb-amd64/31/linux append vga=normal initrd=deb-amd64/31/initrd.gz ramdisk_size=10800 root=/dev/rd/0 devfs=mount,dall rw languagechooser/ language-name=English countrychooser/shortlist=ES console-keymaps-at/ keymap=es preseed/url=http://ks.xxx.net/deb/sarge -- There are too many boot parameters, so we get a kernel panic: -- Kernel panic: Too many boot env vars at `BOOT_IMAGE=deb-amd64´ In idle task - not syncing -- So my question is: Is there anyway to auto-select language, country, keyboard layout, etc.. and preseed a file too by appeding parameters to the kernel? If I only put preseed parameter I'm prompted to manually select language, country, etc.. :-( Regards,
Re: Too many env vars in an automated PXE/preseed Debian installation
Santi Saez wrote: I am trying to automate Debian installation in a Dell PowerEdge server via PXE-boot and preseeding files. I want to automatically select language, country, keyboard layout, etc.. and pass preseed file, those are the kernel parameters that are appending via pxelinux boot: -- label sarge-amd64 kernel deb-amd64/31/linux append vga=normal initrd=deb-amd64/31/initrd.gz ramdisk_size=10800 root=/dev/rd/0 devfs=mount,dall rw languagechooser/ language-name=English countrychooser/shortlist=ES console-keymaps-at/ keymap=es preseed/url=http://ks.xxx.net/deb/sarge -- There are too many boot parameters, so we get a kernel panic: -- Kernel panic: Too many boot env vars at `BOOT_IMAGE=deb-amd64´ In idle task - not syncing -- So my question is: Is there anyway to auto-select language, country, keyboard layout, etc.. and preseed a file too by appeding parameters to the kernel? If I only put preseed parameter I'm prompted to manually select language, country, etc.. :-( You can remove the vga=normal to save one parameter, which should get things working for you. In etch the kernel parameter limit is increased and some parameters are combined (eg debian-installer/locale=en_US) which makes this sort of preseeding much easier. -- see shy jo signature.asc Description: Digital signature
Re: XTerm verschluckt die Env.-Variable TMPDIR
Helmut Waitzmann [EMAIL PROTECTED] writes:
»execargs«
ist ein Programm, das mit seinen Parametern argv[1] argv[2] ... die
Funktion execvp(argv[1], { argv[2], argv[3], ...}) aufruft.
$ TMPDIR=/tmp execargs printenv printenv TMPDIR; printf 'Exit Code: %s\n' $?
/tmp
Exit Code: 0
Setze ich jetzt bei »execargs« das Setuid- oder Setgid-Flag auf eine
Benutzer- oder Gruppenkennung, die sich von meiner unterscheidet, erhalte
ich folgende Ausgabe:
$ TMPDIR=/tmp execargs printenv printenv TMPDIR; printf 'Exit Code: %s\n' $?
Exit Code: 1
Das scheint also eine Eigenschaft der Laufzeitumgebung zu sein. »xterm«
tut es also nicht explizit.
Das selbe in grün mit screen(1). Es scheinen also wohl alle suid- und
sgid-Programme betroffen zu sein.
Die Vermutung liegt nahe, dass die Ursache im C-library oder im
Startup-Code liegt.
--
Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please
Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with
meinen Vor- und Nachnamen, etwa so: | my full name, like
Helmut Waitzmann [EMAIL PROTECTED], (Helmut Waitzmann) [EMAIL PROTECTED]
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: XTerm verschluckt die Env.-Variable TMPDIR
Am 2006-04-07 00:29:33, schrieb Helmut Waitzmann: Der Fehler ist alt und bestand schon in Woody: Fehlerbericht Nr. 276417 im Debian Bug Tracking System. Erinnerst Du Dich? Ja, habs jetzt nachgelesen... Komisch ist nur, das dieser BUG erst jetzt nach der umstellung auf Sarge auftauchte, denn unter Woody hatte ich TMPDIR und bis vor ein paar Wochen keine Probleme. Ich habe damals nach Branden Robinsons Aussage »xterm contains no logic for scrubbing the environment.« aus Zeitgründen klein beigegeben. Der Testfall, der den Fehler beschreibt -- $ env TMPDIR=/tmp xterm -hold -e printenv TMPDIR einerseits und $ env DUMMY=/tmp xterm -hold -e printenv DUMMY andererseits -- lässt keinen Zweifel daran, dass xterm hier TMPDIR verschluckt. Und xterm verschuckt noch mehr... Werde mal in der debian-x nachfragen, denn ich habe jede menge Programme laufen, die massiven DoS Attaken in /tmp ausgesetzt werden können, weshalb ich auf $TMPDIR (/tmp/$USER, chmod 700) angewiesen bin. TMP nach /home/$USER/tmp tu verlagern schlägt fehl, da es sich um ein SSH getunneltes NFS-Share handelt. snip Das scheint also eine Eigenschaft der Laufzeitumgebung zu sein. »xterm« tut es also nicht explizit. Da heist es also die xterm Source umzugraben... Greetings Michelle Konzack -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: XTerm verschluckt die Env.-Variable TMPDIR
Michelle Konzack [EMAIL PROTECTED] writes:
Am 2006-03-23 16:31:29, schrieb Friedhelm Usenet Waitzmann:
Bekannt. Xterm in sarge verschluckt die Environmentvariable
Bekannt? - Also ich bin gerade noch mal das BTS von xfree86
durchgegangen und habe in den tausenden messages nichts gefunden...
Wo haste das gelesen?
Der Fehler ist alt und bestand schon in Woody: Fehlerbericht Nr. 276417
im Debian Bug Tracking System. Erinnerst Du Dich?
Ich habe damals nach Branden Robinsons Aussage »xterm contains no logic
for scrubbing the environment.« aus Zeitgründen klein beigegeben.
Der Testfall, der den Fehler beschreibt --
$ env TMPDIR=/tmp xterm -hold -e printenv TMPDIR
einerseits und
$ env DUMMY=/tmp xterm -hold -e printenv DUMMY
andererseits -- lässt keinen Zweifel daran, dass xterm hier TMPDIR
verschluckt.
Vielleicht kann man jetzt einen neuen Anlauf nehmen?
Also, los geht's:
»execargs«
/*
execargs.c - execute arguments via execvp() resp. execv()
2006-04-06T00:56:42+0200
*/
#define _POSIX_SOURCE 1
#define _POSIX_C_SOURCE 199506L
#define _XOPEN_VERSION 4
#include errno.h /* errno, EINVAL, ENOENT, NOEXEC, EACCES */
#include stddef.h /* NULL, size_t */
#include stdio.h /* fprintf(), stderr */
#include stdlib.h /* EXIT_... */
#include string.h /* strerror() */
#include unistd.h /* exec...() */
static const char * invocation_name=execargs;
int
main(int argc, char **argv)
{
if(argc 0 argv[0] != NULL)
{
/* an invocation name is supplied by the OS resp. run
time
* environment
*/
/* strip all leading path components from argv[0], if
there are any:
*/
invocation_name = strrchr(argv[0], '/');
/* invocation_name points to last ocurrence of '/' in
* argv[0] if there is one, otherwise invocation_name is
* NULL
*/
if(invocation_name == NULL)
/* there aren't any '/' characters in argv[0]:
nothing to
* do, just use argv[0] as invocation_name.
*/
invocation_name = argv[0];
else
/* we have found a last '/' character:
invocation_name now
* points to it.
*
* let invocation_name begin after last '/'
character:
*/
invocation_name += 1;
}
/* process option arguments:
*/
if (argc = 2 argv[1] != NULL)
/* At least the name of the program to be executed is given.
*/
{
/* argv[1] is the name of the program to be executed,
argv+2 is its argument vector:
*/
execvp(argv[1], argv+2);
/* if returning from exec...(), an error has occurred:
*/
{
int saved_errno=errno;
{
const char * error_text=strerror(errno);
fprintf(stderr,
%s:\ncannot execute %s%s%s\n,
invocation_name,
argv[1],
(error_text != NULL) ? :\n :
.,
(error_text != NULL) ?
error_text :
);
}
switch(saved_errno)
{
#ifdef ENOENT
case ENOENT:
#endif
return 127;
break;
#ifdef EACCES
case EACCES:
#endif
#ifdef EPERM
case EPERM:
#endif
#ifdef ENOEXEC
case ENOEXEC:
#endif
#ifdef ENOTDIR
case ENOTDIR:
#endif
#ifdef EINVAL
case EINVAL:
#endif
#ifdef EISDIR
case EISDIR:
#endif
#ifdef ELIBBAD
case ELIBBAD:
#endif
return 126;
break;
default
Re: XTerm verschluckt die Env.-Variable TMPDIR (was: $TMPDIR funktioniert unter x-window/fvwm nicht mehr)
Am 2006-03-23 16:31:29, schrieb Friedhelm Usenet Waitzmann: Bekannt. Xterm in sarge verschluckt die Environmentvariable Bekannt? - Also ich bin gerade noch mal das BTS von xfree86 durchgegangen und habe in den tausenden messages nichts gefunden... Wo haste das gelesen? TMPDIR. Allerdings weiß ich nichts davon, dass das nicht auftreten soll, wenn man das Xterm automatisch ein $SHELL Genau, denn wenn Du ein xterm -e /bin/bash -c /usr/bin/mc machst, wird es nichts, aber mit xterm -e /bin/bash -l -c /usr/bin/mc verwandelt sich die neu aufgerufene SHELL in eine Loginshell und ließt die env ein. Somit steht $TMPDIR wieder zur verfügung. Abhilfe: mit dem Programm env die Belegung dieser Variablen in das von xterm gestartete Programm hineinreichen: xterm -e env TMPDIR=$TMPDIR $SHELL Denke nicht das es einen Unterschied macht, ob ich env oder bash aufrufe. Greetings Michelle Konzack -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
XTerm verschluckt die Env.-Variable TMPDIR (was: $TMPDIR funktioniert unter x-window/fvwm nicht mehr)
Michelle Konzack: Teil der Konfiguration des Windowmanagers fvwm: woody: *ButtonBar1: (Icon 32x32.xterm.xpm, Action 'Exec xterm -geometry 92x29+0+150 -fn 10x20 -title xterm -name xterm -n xterm -bg blue -fg white -sb -sl 8192 ') *ButtonBar1: (Icon 32x32.filemgr.xpm, Action 'Exec xterm -geometry 94x29+0+150 -fn 10x20 -title Midnight Commander -name mc-n mc-e /usr/bin/mc ') *ButtonBar1: (Icon 32x32.mutt.xpm,Action 'Exec xterm -geometry 80x28+0+170 -fn 10x20 -title mutt -name mutt -n mutt -e /usr/bin/mutt ') sarge: *ButtonBar1: (Icon 32x32.xterm.xpm, Action 'Exec xterm -geometry 92x29+0+150 -fn 10x20 -title xterm -name xterm -n xterm -bg blue -fg white -sb -sl 8192 ') *ButtonBar1: (Icon 32x32.filemgr.xpm, Action 'Exec xterm -geometry 94x29+0+150 -fn 10x20 -title Midnight Commander -name mc-n mc-e /bin/bash -l -c /usr/bin/mc ') *ButtonBar1: (Icon 32x32.mutt.xpm,Action 'Exec xterm -geometry 80x28+0+170 -fn 10x20 -title mutt -name mutt -n mutt -e /bin/bash -l -c /usr/bin/mutt ') Do you see it? the first line is the same as the line under Wooody and it works. But xterm called for mc and mutt does not work and need additionaly /bin/bash -l -c ... Was sagste jetzt dazu? Bekannt. Xterm in sarge verschluckt die Environmentvariable TMPDIR. Allerdings weiß ich nichts davon, dass das nicht auftreten soll, wenn man das Xterm automatisch ein $SHELL starten lässt, sondern nur, wenn man mit -e program [ arg ]... ein Programm angibt. Abhilfe: mit dem Programm env die Belegung dieser Variablen in das von xterm gestartete Programm hineinreichen: xterm -e env TMPDIR=$TMPDIR $SHELL bzw. xterm -e env TMPDIR=$TMPDIR mutt -- Bitte in die Adressierung auch meinen|Please put my full name also into Vor- u. Nachnamen stellen z.B. |the recipient like Friedhelm Waitzmann [EMAIL PROTECTED], (Friedhelm Waitzmann) [EMAIL PROTECTED], Waitzmann, Friedhelm [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
/etc/init.d/* vs. /usr/bin/env
Hallo zusammen, bei der Installation von DenyHosts (gegen SSH brute force attacks; nicht Teil von Sarge) auf ein Sarge-System bin ich auf folgendes Problem gestossen: Sowohl das beiliegende Startscript als auch denyhosts.py selbst verwenden #!/usr/bin/env python. So eingeloggt kann ich das Script mit /etc/init.d/denyhosts start starten (als root; es handelt sich dabei um ein nicht-Debian Python-Startscript, das denyhosts mit der Option --daemon startet). Um DenyHosts allerdings aus dem Runlevel aus zu starten, musste ich in beiden Scripts die Interpeter-Zeile in den absoluten Pfad zum Python-Binary aendern. Waehrend /etc/init.d/denyhosts Upgrades ueberdauert, muss ich denyhosts.py bei jedem Upgrade von Hand aendern, was mir zu fehleranfaellig ist. Ich hoffe, dass klar genug geworden ist, wo das Problem liegt, und dass jemand mir einen Fingerzeig in Richtung einer dauerhaften Loesung geben kann. Tschoe, -Andre -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: /etc/init.d/* vs. /usr/bin/env
On 11.01.06 18:28:40, Andre Berger wrote: bei der Installation von DenyHosts (gegen SSH brute force attacks; nicht Teil von Sarge) auf ein Sarge-System bin ich auf folgendes Problem gestossen: Sowohl das beiliegende Startscript als auch denyhosts.py selbst verwenden #!/usr/bin/env python. So eingeloggt kann ich das Script mit /etc/init.d/denyhosts start starten (als root; es handelt sich dabei um ein nicht-Debian Python-Startscript, das denyhosts mit der Option --daemon startet). Hast du den Sinn der Zeile verstanden? Um DenyHosts allerdings aus dem Runlevel aus zu starten, musste ich in beiden Scripts die Interpeter-Zeile in den absoluten Pfad zum Python-Binary aendern. Hmm, wo ist das Python denn installiert? /usr/bin sollte doch auch bei Skripten in /etc/init.d im Pfad liegen oder irre ich mich da jetzt? Waehrend /etc/init.d/denyhosts Upgrades ueberdauert, muss ich denyhosts.py bei jedem Upgrade von Hand aendern, was mir zu fehleranfaellig ist. Klaro, aber du koenntest das init.d-Skript so abaendern das die PATH-Variable mit dem Pfad zum python-Binary erweitert wird. Danach sollte env in dem denyhosts.py Skript auch den neuen PATH enthalten und somit python finden. Andreas -- You love your home and want it to be beautiful. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: /etc/init.d/* vs. /usr/bin/env
* Andreas Pakulat (2006-01-11):
On 11.01.06 18:28:40, Andre Berger wrote:
bei der Installation von DenyHosts (gegen SSH brute force attacks;
nicht Teil von Sarge) auf ein Sarge-System bin ich auf folgendes
Problem gestossen: Sowohl das beiliegende Startscript als auch
denyhosts.py selbst verwenden #!/usr/bin/env python. So eingeloggt
kann ich das Script mit /etc/init.d/denyhosts start starten (als
root; es handelt sich dabei um ein nicht-Debian Python-Startscript,
das denyhosts mit der Option --daemon startet).
Hast du den Sinn der Zeile verstanden?
Wie meinen? DenyHosts laeuft eben als Daemon und wird alle dreissig
Sekunden aktiv. Dass es als root laeuft, ist nicht optimal, aber
daran bastele ich spaeter mit Hilfe der DenyHosts-FAQ. Oder meintest
du das Shebang?
Um DenyHosts allerdings aus dem Runlevel aus zu starten, musste ich
in beiden Scripts die Interpeter-Zeile in den absoluten Pfad zum
Python-Binary aendern.
Hmm, wo ist das Python denn installiert? /usr/bin sollte doch auch bei
Skripten in /etc/init.d im Pfad liegen oder irre ich mich da jetzt?
Vielen Dank, das hat mich zur Loesung gefuehrt. Ich hatte python-2.3
installiert und mit update-alternatives /etc/alternatives/python
erzeugt -- genauer gesagt manuell erzeugen muessen, da apt-get
install es nicht von sich aus tat.
Ich stelle nun allerdings fest, dass kein Link /usr/bin/python
erzeugt wurde und which python auf meinen manuellen Symlink
/usr/local/bin/python zeigte. Nach dem Erzeugen von Symlinks von
/etc/alternatives/py{thon,gettext,doc} nach /usr/bin/ klappt es nun
wie gewuenscht.
Waehrend /etc/init.d/denyhosts Upgrades ueberdauert, muss ich
denyhosts.py bei jedem Upgrade von Hand aendern, was mir zu
fehleranfaellig ist.
Klaro, aber du koenntest das init.d-Skript so abaendern das die
PATH-Variable mit dem Pfad zum python-Binary erweitert wird. Danach
sollte env in dem denyhosts.py Skript auch den neuen PATH enthalten und
somit python finden.
Interessehalber: Wie setz man denn eine globale Variable in Python
auf den Wert einer Shell-Variablen?
-Andre
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: /etc/init.d/* vs. /usr/bin/env
On 11.01.06 20:43:27, Andre Berger wrote:
* Andreas Pakulat (2006-01-11):
On 11.01.06 18:28:40, Andre Berger wrote:
bei der Installation von DenyHosts (gegen SSH brute force attacks;
nicht Teil von Sarge) auf ein Sarge-System bin ich auf folgendes
Problem gestossen: Sowohl das beiliegende Startscript als auch
denyhosts.py selbst verwenden #!/usr/bin/env python. So eingeloggt
kann ich das Script mit /etc/init.d/denyhosts start starten (als
root; es handelt sich dabei um ein nicht-Debian Python-Startscript,
das denyhosts mit der Option --daemon startet).
Hast du den Sinn der Zeile verstanden?
Wie meinen? DenyHosts laeuft eben als Daemon und wird alle dreissig
Sekunden aktiv. Dass es als root laeuft, ist nicht optimal, aber
daran bastele ich spaeter mit Hilfe der DenyHosts-FAQ. Oder meintest
du das Shebang?
Genau das Shebang, insbesondere das du dir anguckst was env eigentlich
bewirkt und warum dann das richtige Python aufgerufen wird.
Um DenyHosts allerdings aus dem Runlevel aus zu starten, musste ich
in beiden Scripts die Interpeter-Zeile in den absoluten Pfad zum
Python-Binary aendern.
Hmm, wo ist das Python denn installiert? /usr/bin sollte doch auch bei
Skripten in /etc/init.d im Pfad liegen oder irre ich mich da jetzt?
Vielen Dank, das hat mich zur Loesung gefuehrt. Ich hatte python-2.3
installiert und mit update-alternatives /etc/alternatives/python
erzeugt -- genauer gesagt manuell erzeugen muessen, da apt-get
install es nicht von sich aus tat.
Das liegt daran, dass die Python-Pakete nicht das Alternatives-System
nutzen. Die Python-Pakete installieren selbststaendig einen Symlink
/usr/bin/python der auf die richtige Version zeigt. Bzw. tut das Paket
python dies.
Ich stelle nun allerdings fest, dass kein Link /usr/bin/python
erzeugt wurde und which python auf meinen manuellen Symlink
/usr/local/bin/python zeigte.
Das wird der Grund gewesen sein, IIRC ist PATH initial auf
/bin:/sbin:/usr/sbin:/usr/bin wenn root die UID ist. Somit wird python
nicht gefunden.
Nach dem Erzeugen von Symlinks von
/etc/alternatives/py{thon,gettext,doc} nach /usr/bin/ klappt es nun
wie gewuenscht.
apt-get install python loest das Problem ohne manuelles Eingreifen.
Analog gcc installiert dir das immer nen Symlink auf das aktuelle
Default-Python.
Waehrend /etc/init.d/denyhosts Upgrades ueberdauert, muss ich
denyhosts.py bei jedem Upgrade von Hand aendern, was mir zu
fehleranfaellig ist.
Klaro, aber du koenntest das init.d-Skript so abaendern das die
PATH-Variable mit dem Pfad zum python-Binary erweitert wird. Danach
sollte env in dem denyhosts.py Skript auch den neuen PATH enthalten und
somit python finden.
Interessehalber: Wie setz man denn eine globale Variable in Python
auf den Wert einer Shell-Variablen?
Das willst du doch gar nicht, was du machen wollen wuerdest waere die
PATH-Variable zu erweitern und damit das 2. Python-Skript ausfuehren.
Wie das genau aussieht weiss ich so aber auch nicht.
Andreas
--
You never know how many friends you have until you rent a house on the beach.
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: /etc/init.d/* vs. /usr/bin/env
* Andreas Pakulat (2006-01-11):
On 11.01.06 20:43:27, Andre Berger wrote:
* Andreas Pakulat (2006-01-11):
On 11.01.06 18:28:40, Andre Berger wrote:
bei der Installation von DenyHosts (gegen SSH brute force attacks;
nicht Teil von Sarge) auf ein Sarge-System bin ich auf folgendes
Problem gestossen: Sowohl das beiliegende Startscript als auch
denyhosts.py selbst verwenden #!/usr/bin/env python. So eingeloggt
kann ich das Script mit /etc/init.d/denyhosts start starten (als
root; es handelt sich dabei um ein nicht-Debian Python-Startscript,
das denyhosts mit der Option --daemon startet).
Hast du den Sinn der Zeile verstanden?
Wie meinen? DenyHosts laeuft eben als Daemon und wird alle dreissig
Sekunden aktiv. Dass es als root laeuft, ist nicht optimal, aber
daran bastele ich spaeter mit Hilfe der DenyHosts-FAQ. Oder meintest
du das Shebang?
Genau das Shebang, insbesondere das du dir anguckst was env eigentlich
bewirkt und warum dann das richtige Python aufgerufen wird.
Das ist mir schon klar, ich fand nur keinen Grund dafuer, dass es mit
meinem (einzigen) Python von der Kommandozeile aus ja, aus dem
Init-Script heraus aber nicht ging. Ich tippe auf einen Fehler in
meiner update-alternatives-Syntax.
Um DenyHosts allerdings aus dem Runlevel aus zu starten, musste ich
in beiden Scripts die Interpeter-Zeile in den absoluten Pfad zum
Python-Binary aendern.
Hmm, wo ist das Python denn installiert? /usr/bin sollte doch auch bei
Skripten in /etc/init.d im Pfad liegen oder irre ich mich da jetzt?
Vielen Dank, das hat mich zur Loesung gefuehrt. Ich hatte python-2.3
installiert und mit update-alternatives /etc/alternatives/python
erzeugt -- genauer gesagt manuell erzeugen muessen, da apt-get
install es nicht von sich aus tat.
Das liegt daran, dass die Python-Pakete nicht das Alternatives-System
nutzen. Die Python-Pakete installieren selbststaendig einen Symlink
/usr/bin/python der auf die richtige Version zeigt. Bzw. tut das Paket
python dies.
python2.3 tat das hier jedenfalls nicht.
Ich stelle nun allerdings fest, dass kein Link /usr/bin/python
erzeugt wurde und which python auf meinen manuellen Symlink
/usr/local/bin/python zeigte.
Das wird der Grund gewesen sein, IIRC ist PATH initial auf
/bin:/sbin:/usr/sbin:/usr/bin wenn root die UID ist. Somit wird python
nicht gefunden.
So erklaere ich mir das nachtraeglich auch.
Nach dem Erzeugen von Symlinks von
/etc/alternatives/py{thon,gettext,doc} nach /usr/bin/ klappt es nun
wie gewuenscht.
apt-get install python loest das Problem ohne manuelles Eingreifen.
Analog gcc installiert dir das immer nen Symlink auf das aktuelle
Default-Python.
Das war also der Trick. Ich hatte per apt-cache search python mit
einem Auge gesehen, dass es auch 2.2er-Pakete gibt und irgendwie
gleich vermutet, dass die aelteste Version der Debian stable-Default
ist :) Da DenyHosts python2.3 benoetigt, habe ich dies Paket eben
direkt installiert.
Waehrend /etc/init.d/denyhosts Upgrades ueberdauert, muss ich
denyhosts.py bei jedem Upgrade von Hand aendern, was mir zu
fehleranfaellig ist.
Klaro, aber du koenntest das init.d-Skript so abaendern das die
PATH-Variable mit dem Pfad zum python-Binary erweitert wird. Danach
sollte env in dem denyhosts.py Skript auch den neuen PATH enthalten und
somit python finden.
Interessehalber: Wie setz man denn eine globale Variable in Python
auf den Wert einer Shell-Variablen?
Das willst du doch gar nicht, was du machen wollen wuerdest waere die
PATH-Variable zu erweitern und damit das 2. Python-Skript ausfuehren.
Das war es, was ich wollte.
Wie das genau aussieht weiss ich so aber auch nicht.
Ist nicht tragisch, ich bin sehr zufrieden, dass es jetzt laeuft.
Vielen Dank fuer deine Hilfe, much appreciated.
-Andre
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: /etc/init.d/* vs. /usr/bin/env
On 11.01.06 23:38:25, Andre Berger wrote: * Andreas Pakulat (2006-01-11): On 11.01.06 20:43:27, Andre Berger wrote: Wie meinen? DenyHosts laeuft eben als Daemon und wird alle dreissig Sekunden aktiv. Dass es als root laeuft, ist nicht optimal, aber daran bastele ich spaeter mit Hilfe der DenyHosts-FAQ. Oder meintest du das Shebang? Genau das Shebang, insbesondere das du dir anguckst was env eigentlich bewirkt und warum dann das richtige Python aufgerufen wird. Das ist mir schon klar, ich fand nur keinen Grund dafuer, dass es mit meinem (einzigen) Python von der Kommandozeile aus ja, aus dem Init-Script heraus aber nicht ging. Das liegt einfach daran dass dein User eine andere Umgebung hat als root (root startet das init-Script). Unter anderem werden bei normalen Usern bei Default-Einstellungen eben /usr/local/bin und falls existent auch $HOME/bin in PATH aufgenommen. root's PATH enthaelt per Default nur /bin,/usr/bin,/sbin und /usr/sbin. Ich tippe auf einen Fehler in meiner update-alternatives-Syntax. Vergiss alternatives. Um DenyHosts allerdings aus dem Runlevel aus zu starten, musste ich in beiden Scripts die Interpeter-Zeile in den absoluten Pfad zum Python-Binary aendern. Hmm, wo ist das Python denn installiert? /usr/bin sollte doch auch bei Skripten in /etc/init.d im Pfad liegen oder irre ich mich da jetzt? Vielen Dank, das hat mich zur Loesung gefuehrt. Ich hatte python-2.3 installiert und mit update-alternatives /etc/alternatives/python erzeugt -- genauer gesagt manuell erzeugen muessen, da apt-get install es nicht von sich aus tat. Das liegt daran, dass die Python-Pakete nicht das Alternatives-System nutzen. Die Python-Pakete installieren selbststaendig einen Symlink /usr/bin/python der auf die richtige Version zeigt. Bzw. tut das Paket python dies. python2.3 tat das hier jedenfalls nicht. Ich sagte doch, das Paket python installiert einen Symlink /usr/bin/python der auf das aktuelle Debian-Default-Python-Binary (im Moment noch python2.3) zeigt. Ich stelle nun allerdings fest, dass kein Link /usr/bin/python erzeugt wurde und which python auf meinen manuellen Symlink /usr/local/bin/python zeigte. Das wird der Grund gewesen sein, IIRC ist PATH initial auf /bin:/sbin:/usr/sbin:/usr/bin wenn root die UID ist. Somit wird python nicht gefunden. So erklaere ich mir das nachtraeglich auch. So ist es auch, entferne mal dein alternatives-Zeug und es wird wieder nicht gehen. apt-get install python loest das Problem ohne manuelles Eingreifen. Analog gcc installiert dir das immer nen Symlink auf das aktuelle Default-Python. Das war also der Trick. Ich hatte per apt-cache search python mit einem Auge gesehen, dass es auch 2.2er-Pakete gibt und irgendwie gleich vermutet, dass die aelteste Version der Debian stable-Default ist :) Da DenyHosts python2.3 benoetigt, habe ich dies Paket eben direkt installiert. Nein, seit Sarge ist python2.3 Default bei Debian. So angestaubt ist es dann auch nicht ;-) Andreas -- Live in a world of your own, but always welcome visitors. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Afficher le résultat d'un script dans un env. graphique
2005/12/8, Frédéric BOITEUX [EMAIL PROTECTED]: Bonjour, Voilà, je cherche un petit programme qui m'ouvrirait une fenêtre dans laquelle s'afficherait la sortie d'un script système... Un peu l'équivalent d'un : rxvt -e bash -c 'script | less +F' mais qui serait un peu plus facile à lire pour un simple utilisateur (avec des boutons annulation/ok, un ascenceur, ... bref qq chose de plus amical pour un non-geek. Il y a bien xmessage, mais ce n'est pas terrible (et je ne crois pas qu'il sache gérer un affichage au fil de l'eau d'un script qui prend du temps...) Tout dépend de la complexité que tu veux bien programmer. xdialog Tk (mais il faudra passer à Tcl, Perl, Python, enfin, bref, pas bash) PK -- |\ _,,,---,,_ Patrice KARATCHENTZEFF ZZZzz /,`.-'`'-. ;-;;,_ mailto:[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' http://p.karatchentzeff.free.fr '---''(_/--' `-'\_)
Re: Afficher le résultat d'un script dans un env. graphique
Le Thu, 8 Dec 2005 09:22:20 +0100, Patrice Karatchentzeff [EMAIL PROTECTED] a écrit : Tout dépend de la complexité que tu veux bien programmer. xdialog Tk (mais il faudra passer à Tcl, Perl, Python, enfin, bref, pas bash) Merci Patrice. Je pensais effectiveent faire une appli Perl-Tk (que je connais un peu), mais vu que c'est un problème assez général, je me demandais si une solution n'avait pas déjà été produite ! Fred.
Re: Afficher le résultat d'un script dans un env. graphique
On Thu, 8 Dec 2005 08:34:29 +0100 Frédéric BOITEUX [EMAIL PROTECTED] wrote: Voilà, je cherche un petit programme qui m'ouvrirait une fenêtre dans laquelle s'afficherait la sortie d'un script système... Un peu l'équivalent d'un : rxvt -e bash -c 'script | less +F' mais qui serait un peu plus facile à lire pour un simple utilisateur (avec des boutons annulation/ok, un ascenceur, ... bref qq chose de plus amical pour un non-geek. Il y a bien xmessage, mais ce n'est pas terrible (et je ne crois pas qu'il sache gérer un affichage au fil de l'eau d'un script qui prend du temps...) Pas testé, mais j'en ai déjà entendu parler : zenity. $ apt-cache show zenity Package: zenity [..] Description: Display graphical dialog boxes from shell scripts Zenity allows you to display GTK+ dialogs from shell scripts; it is a rewrite of the `gdialog' command from GNOME 1. . Zenity includes a gdialog wrapper script so that it can be used with legacy scripts. -- Benjamin -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Afficher le résultat d'un script dans un env. graphique
Le 08/12/05, Benjamin Sigonneau[EMAIL PROTECTED] a écrit : [...] Pas testé, mais j'en ai déjà entendu parler : zenity. whaou... j'ai testé : c'est bluffant. Je sens que je vais adopter aussi. PK -- |\ _,,,---,,_ Patrice KARATCHENTZEFF ZZZzz /,`.-'`'-. ;-;;,_ mailto:[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' http://p.karatchentzeff.free.fr '---''(_/--' `-'\_)
Re: Afficher le résultat d'un script dans un env. graphique
Le Thu, 8 Dec 2005 13:49:49 +0100, Patrice Karatchentzeff [EMAIL PROTECTED] a écrit : whaou... j'ai testé : c'est bluffant. Je sens que je vais adopter aussi. Effectivement, c'est simple à utiliser et le résultat est très propre. C'est plus limité que 'dialog' (un seul widget), mais une bonne solution pour ce que je voulais faire : mon script | zenity --text-info Merci, Fred.
Re: Afficher le résulta t d'un script dans un env. graphique
On Thu, Dec 08, 2005 at 02:08:05PM +0100, Frédéric BOITEUX wrote: Effectivement, c'est simple à utiliser et le résultat est très propre. C'est plus limité que 'dialog' (un seul widget), mais en plus évolué, comme indiqué plus haut, il y a xdialog, qui n'est qu'une adaptation X11 de dialog. -- Thomas Clavier http://www.tcweb.org Lille Sans Fil http://www.lillesansfil.org +33 (0)6 20 81 81 30JabberID : [EMAIL PROTECTED] -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Afficher le résultat d'un script dans un env. graphique
Le 08/12/05, Thomas Clavier[EMAIL PROTECTED] a écrit : On Thu, Dec 08, 2005 at 02:08:05PM +0100, Frédéric BOITEUX wrote: Effectivement, c'est simple à utiliser et le résultat est très propre. C'est plus limité que 'dialog' (un seul widget), mais en plus évolué, comme indiqué plus haut, il y a xdialog, qui n'est qu'une adaptation X11 de dialog. Il y a aussi ce qu'utilise debconf : whiptail. PK -- |\ _,,,---,,_ Patrice KARATCHENTZEFF ZZZzz /,`.-'`'-. ;-;;,_ mailto:[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' http://p.karatchentzeff.free.fr '---''(_/--' `-'\_)
Afficher le résultat d'un script dans un env. graphique
Bonjour, Voilà, je cherche un petit programme qui m'ouvrirait une fenêtre dans laquelle s'afficherait la sortie d'un script système... Un peu l'équivalent d'un : rxvt -e bash -c 'script | less +F' mais qui serait un peu plus facile à lire pour un simple utilisateur (avec des boutons annulation/ok, un ascenceur, ... bref qq chose de plus amical pour un non-geek. Il y a bien xmessage, mais ce n'est pas terrible (et je ne crois pas qu'il sache gérer un affichage au fil de l'eau d'un script qui prend du temps...) Si vous avez des idées, je suis preneur ! bonne journée, Fred.
Re: How to share env. variables ?
hi, put those contents(environment variables) in .bashrc. because .bashrc is the file that is read in for non-interactive terminals like kterm or gnome-terminal or any such application. sac. On 10/27/05, Marc Wilson [EMAIL PROTECTED] wrote: On Fri, Oct 21, 2005 at 11:06:33AM -0500, Hugo Vanwoerkom wrote: I asked that question a while ago. It appears e.g. that xterm uses /etc/profile and konsole does not. How to change that behavior? Xterm does not use /etc/profile, and neither does konsole. Or gnome-terminal, or rxvt, or any other terminal emulator. You appear to be confused wrt the difference between a terminal emulator (xterm), and the application running inside it (bash, usually). Read the INVOCATION section of the bash man page. Then you'll understand when and how bash uses which of the various startup files it honors. Then read the xterm man page, and you'll understand how to invoke xterm in order to get it to launch bash in the way you want. -- Marc Wilson | Simulations are like miniskirts, they show a lot [EMAIL PROTECTED] | and hide the essentials. -- Hubert Kirrman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to share env. variables ?
On Fri, Oct 21, 2005 at 11:06:33AM -0500, Hugo Vanwoerkom wrote: I asked that question a while ago. It appears e.g. that xterm uses /etc/profile and konsole does not. How to change that behavior? Xterm does not use /etc/profile, and neither does konsole. Or gnome-terminal, or rxvt, or any other terminal emulator. You appear to be confused wrt the difference between a terminal emulator (xterm), and the application running inside it (bash, usually). Read the INVOCATION section of the bash man page. Then you'll understand when and how bash uses which of the various startup files it honors. Then read the xterm man page, and you'll understand how to invoke xterm in order to get it to launch bash in the way you want. -- Marc Wilson | Simulations are like miniskirts, they show a lot [EMAIL PROTECTED] | and hide the essentials. -- Hubert Kirrman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to share env. variables ?
On Saturday 22 October 2005 10:35, Hugo Vanwoerkom wrote: Andrew Nelson wrote: On Fri, 21 Oct 2005 11:06:33 -0500 Hugo Vanwoerkom [EMAIL PROTECTED] wrote: Bruno Costacurta wrote: Hello, I setup some environment variables needed by applications in user .bash files. Starting these applications from a console works fine. But starting these applications from kde menus don't work as obviously these user env.variables are not set. I suppose kde user is different than logged user. How to give kde / X11 same env.variables as logged user ? I asked that question a while ago. It appears e.g. that xterm uses /etc/profile and konsole does not. How to change that behavior? H I don't use konsole but it appears this thread might help. http://www.kde-forum.org/artikel/5064/Configuring-and-Customizing-Konsole .html Andy: Hot tip. I sourced /etc/profile to .bashrc. I was thinking of doing that earlier but the thread confirmed it. H Hugo, what do you mean by 'I sourced /etc/profile to .bashrc' ? Thanks, Bruno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to share env. variables ?
Andrew Nelson wrote: On Fri, 21 Oct 2005 11:06:33 -0500 Hugo Vanwoerkom [EMAIL PROTECTED] wrote: Bruno Costacurta wrote: Hello, I setup some environment variables needed by applications in user .bash files. Starting these applications from a console works fine. But starting these applications from kde menus don't work as obviously these user env.variables are not set. I suppose kde user is different than logged user. How to give kde / X11 same env.variables as logged user ? I asked that question a while ago. It appears e.g. that xterm uses /etc/profile and konsole does not. How to change that behavior? H I don't use konsole but it appears this thread might help. http://www.kde-forum.org/artikel/5064/Configuring-and-Customizing-Konsole.html Andy: Hot tip. I sourced /etc/profile to .bashrc. I was thinking of doing that earlier but the thread confirmed it. H -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to share env. variables ?
On Saturday 22 October 2005 00:54, Paulo M C Aragão wrote: Bruno, How to give kde / X11 same env.variables as logged user ? KDE sources all shell scripts placed in ~/.kde/env. What I do is: 1. ln -s /etc/environment ~/.kde/env 2. Place all global environment variables in /etc/environment This way they're available to console and KDE-started appl alike. Paulo Paulo, could you please provide some samples like setting PATH in /etc/environment ? Many thanks. Bruno
Règles udev : signification de ENV {ID_MODEL}
Bonjour la liste,
je me suis enfin décidé à créer mes règles udev et j'aurais quelques
questions. Bon je commence par celle du sujet :
1) Dans udev.rules j'ai, dans la ligne qui semble gérer l'IDE (disques
dur et lecteurs/graveurs CD/DVD), la clé d'identification suivante :
ENV{ID_MODEL}
Que signifie-t-elle ?
Je recopie la ligne entière :
# workaround for devices which do not report media changes
BUS==ide, KERNEL==hd[a-z], SYSFS{removable}==1, \
ENV{ID_MODEL}==IOMEGA_ZIP*, NAME=%k, OPTIONS+=all_partitions
Ce qui me perturbe ici c'est le IOMEGA_ZIP. Visiblement cela ne semble
pas perturber udev, bien que je n'ait pas de disquette iomega puisque
mes disque dur et lecteurs divers sont bien créé. Si la signification de
ENV n'explique pas cet état de fait, pourriez-vous me donner des
indications ?
2) Dans la doc de udev il est écrit que udev lit les fichiers .rules
uniquement et ceci par ordre lexicographique dans le répertoire
/etc/udev/rules.d (qui contient les liens symbolique vers les vraies
règles). Il est également écrit que si l'on veut créer ses propres
règles il faut les créer dans /etc/udev dans de nouveaux fichiers et
faire un lien symbolique dans /etc/udev/rules.d et trouver un nom pour
que cela soit lu avant les règles par défaut (celles présentes à
l'installation du package). De là deux questions :
- Si le nom du lien symbolique de mes règles est bien antérieur au nom
du lien symbolique de udev.rules (par exemple) mais qu'au niveau des
vrais fichiers ce soit l'inverse, est-ce que mes règles seront bien
prises en compte (en gros est-ce bien l'ordre lexicographique sur les
liens qui importe ou sur les fichiers réels ?) ?
- Si udev trouve une correspondance dans mes règles, cherchera-t-il une
correspondance dans les règles udev par défaut (j'ai bien compris que si
udev trouve une correspondance dans une de mes règles il ne regardera
pas les suivantes mais cela reste-t-il vrai pour l'ensemble des règles
mises en jeu ?) ?
3) Dernière question : Le but a terme est de faire du montage
automatique donc j'avais pensé à installer autofs (je suis sous kde donc
je pensais éviter gvm) mais il semble que hal soit conseillé avec udev.
Qu'apporte-t-il de plus ? J'ai lu un peu sur wikipedia et il semble
qu'il s'agisse d'abstraction vis à vis du matériel (ce qui est bien)
mais concrêtement ça change quoi pour moi ?
Merci beaucoup pour vos réponses.
RTyler
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To:
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Règles udev : signification de ENV{ID_MODEL}
RTyler a écrit :
Bonjour la liste,
je me suis enfin décidé à créer mes règles udev et j'aurais quelques
questions. Bon je commence par celle du sujet :
1) Dans udev.rules j'ai, dans la ligne qui semble gérer l'IDE (disques
dur et lecteurs/graveurs CD/DVD), la clé d'identification suivante :
ENV{ID_MODEL}
Que signifie-t-elle ?
Je recopie la ligne entière :
# workaround for devices which do not report media changes
BUS==ide, KERNEL==hd[a-z], SYSFS{removable}==1, \
ENV{ID_MODEL}==IOMEGA_ZIP*, NAME=%k,
OPTIONS+=all_partitions
Ce qui me perturbe ici c'est le IOMEGA_ZIP. Visiblement cela ne semble
pas perturber udev, bien que je n'ait pas de disquette iomega puisque
mes disque dur et lecteurs divers sont bien créé. Si la signification
de ENV n'explique pas cet état de fait, pourriez-vous me donner des
indications ?
Premier élément de réponse :
ENV{key}
Match against the value of an environment key. Depending
on the
specified operation, this key is also used as a assignment.
Trouvé dans man udev (je pensais, à tort, qu'il n'y avait pas de man vu
qu'udev n'est pas une commande)
Donc si je comprends bien udev vérifie si la clé d'environnement
(==variable comme LANG ?) ID_MODEL vaut bien IOMEGA_ZIP. Bon déjà je ne
crois pas avoir cette clé (un echo $ID_MODEL ne me donne rien mais
quelque chose me dit que clé d'environnement != variable) et ensuite si
elle existe elle ne vaut probablement pas ça puisqu'il s'agit du disque
dur (hda) et de mes lecteurs (hdc et hdd). Aurais-je raté quelque chose ?
[SNIP]
Je n'ai pas répondu à mes autres interrogation.
RTyler
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To:
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How to share env. variables ?
Hello, I setup some environment variables needed by applications in user .bash files. Starting these applications from a console works fine. But starting these applications from kde menus don't work as obviously these user env.variables are not set. I suppose kde user is different than logged user. How to give kde / X11 same env.variables as logged user ? Thanks, Bruno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to share env. variables ?
Bruno Costacurta wrote: Hello, I setup some environment variables needed by applications in user .bash files. Starting these applications from a console works fine. But starting these applications from kde menus don't work as obviously these user env.variables are not set. I suppose kde user is different than logged user. How to give kde / X11 same env.variables as logged user ? I asked that question a while ago. It appears e.g. that xterm uses /etc/profile and konsole does not. How to change that behavior? H -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to share env. variables ?
On Fri, 21 Oct 2005 11:06:33 -0500 Hugo Vanwoerkom [EMAIL PROTECTED] wrote: Bruno Costacurta wrote: Hello, I setup some environment variables needed by applications in user .bash files. Starting these applications from a console works fine. But starting these applications from kde menus don't work as obviously these user env.variables are not set. I suppose kde user is different than logged user. How to give kde / X11 same env.variables as logged user ? I asked that question a while ago. It appears e.g. that xterm uses /etc/profile and konsole does not. How to change that behavior? H I don't use konsole but it appears this thread might help. http://www.kde-forum.org/artikel/5064/Configuring-and-Customizing-Konsole.html //andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to share env. variables ?
On 2005-10-21 11:06:33 -0500, Hugo Vanwoerkom wrote: Bruno Costacurta wrote: How to give kde / X11 same env.variables as logged user ? If you start X11 with startx, then it will inherit the variable values set for your shell. I asked that question a while ago. It appears e.g. that xterm uses /etc/profile and konsole does not. How to change that behavior? xterm has no reason to read /etc/profile. The difference may be the fact that with your configuration, xterm starts a login shell, but not konsole. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / SPACES project at LORIA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to share env. variables ?
Bruno, How to give kde / X11 same env.variables as logged user ? KDE sources all shell scripts placed in ~/.kde/env. What I do is: 1. ln -s /etc/environment ~/.kde/env 2. Place all global environment variables in /etc/environment This way they're available to console and KDE-started appl alike. Paulo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to share env. variables ?
but how about the Gnome ? thanks! -SharkOn 10/22/05, Paulo M C Aragão [EMAIL PROTECTED] wrote: Bruno, How to give kde / X11 same env.variables as logged user ?KDE sources all shell scripts placed in ~/.kde/env. What I do is:1. ln -s /etc/environment ~/.kde/env2. Place all global environment variables in /etc/environment This way they're available to console and KDE-started appl alike.Paulo--To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]-- I'm just a bitMaker !
KDE, Env-Variablen und dcop-Programmierung
Hallo zusammen, ich verzweifle hier zur Zeit an KDE und ENV-Variablen, evtl. hat hier jemand noch ein paar Ideen oder Links. Ziel: ich möchte über ein Shellscript automatisiert eine aktuell in einem Konqueror-Fenster angezeigte Webseite ausdrucken. das sollte ja prinzipiell nicht das Problem sein. Ist-Zustand: ich kann das entsprechende html-widget wunderbar ansprechen, auch ein interaktiver Druckversuch: $ dcop konqueror-7882 html-widget2 print false funktioniert, dabei geht dann der kprinter-Einstellungsdialog auf. Allerdings kann ich das nicht Automatisieren. print true soll an sich die Sache mit dem default-Drucker automatisch durchführen, allerdings bekomme ich dann eine Fehlermeldung: QUOTE A print error occurred. Error message received from system: cupsdoprint -P '' -J 'http://www.kde.org/' -H 'localhost:631' -U 'andreas' -o ' multiple-document-handling=separate-documents-uncollated-copies orientation-requested=3' '/tmp/kde-andreas/kdeprint_nMTZ4lAb' : execution failed with message: No printer specified (and PRINTER variable is empty) /QUOTE nachdem ich diesen Fehler das erste mal bekommen habe, hab ich manuell den entsprechenden Drucker über /etc/bash.bashrc gesetzt: $ env | grep PRINTER PRINTER=duplex aber anscheinend bekommt KDE nichts davon mit :( denn der Fehler ist unverändert, d.h. die entsprechende Drucker-Variable wird nicht mit -P '' an cupsdoprint übergeben. Fragen: 1. wie bekomme ich diese Information in das KDE-System rein 2. ich möchte das an sich ungern von dem Startzustand abhängig machen da auch mal der PDF-Writer von KDE angesprochen werden soll (wie ich dahin komme weiß ich zwar noch nicht, aber das löse ich dann im Anschluss..), daher, wie kann ich diese Information dann dynamisch in der aktuellen KDE-Session ändern Danke schon mal fürs lesen, Andreas
Re: KDE, Env-Variablen und dcop-Programmierung
On 06.Jul 2005 - 19:16:38, Andreas Loesch wrote: nachdem ich diesen Fehler das erste mal bekommen habe, hab ich manuell den entsprechenden Drucker über /etc/bash.bashrc gesetzt: man bash /etc/bash.bashrc wird nur bei interaktiven nicht-login-shells ausgeführt. Fragen: 1. wie bekomme ich diese Information in das KDE-System rein Kommt drauf an wie du KDE startest und welches KDE du nutzt. Bei Login mittels *dm und KDE3.3 (also Sarge) gibts 2 Moeglichkeiten: 1. Eine .xsession anlegen 2. Das XServer-Skript vom kdm umschreiben. Bei KDE3.4 oder Login ueber login (und Aufruf von startkde) musst du nur dafuer sorgen, dass bash.bashrc in /etc/profile eingelesen wird (da gibts AFAIK eine auskommentierte Zeile fuer). 2. ich möchte das an sich ungern von dem Startzustand abhängig machen da auch mal der PDF-Writer von KDE angesprochen werden soll (wie ich dahin komme weiß ich zwar noch nicht, aber das löse ich dann im Anschluss..), daher, wie kann ich diese Information dann dynamisch in der aktuellen KDE-Session ändern Vermutlich gar nicht. Denn du kommst nicht an die nicht-interaktive Shell die beim Starten von X11 gestartet wird. Du solltest vllt. lieber untersuchen ob du den Drucker mittels dcop setzen kannst. Andreas -- You love peace. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: KDE, Env-Variablen und dcop-Programmierung
Danke für die Antwort, Am Mittwoch, 6. Juli 2005 19:36 schrieb Andreas Pakulat: On 06.Jul 2005 - 19:16:38, Andreas Loesch wrote: man bash /etc/bash.bashrc wird nur bei interaktiven nicht-login-shells ausgeführt. *Klatsch* (Hand vor den Kopf gehauen...) manchmal ist man echt blöd.. Fragen: 1. wie bekomme ich diese Information in das KDE-System rein Kommt drauf an wie du KDE startest und welches KDE du nutzt. Bei Login mittels *dm und KDE3.3 (also Sarge) gibts 2 Moeglichkeiten: ja, sarge mit 3.3 1. Eine .xsession anlegen das soll lt. google bei kdm nicht funktionieren was ich gemacht habe, ein Script in /etc/X11/Xsession.d/ angelegt, dass die Variable PRINTER exportiert. Ergebnis, in einer KDE-Konsole sehe ich die Variable, auch über ein env /tmp/foo.txt im launcher bekomme ich sie zu sehen, sollte also alles funktionieren, aber bei einem $ dcop konqueror-9612 html-widget2 print true bekomme ich immer noch die gleiche Fehlermeldung, als ob die anderen Applikationen nicht die gleiche Umgebung bekommen. Du solltest vllt. lieber untersuchen ob du den Drucker mittels dcop setzen kannst. dazu hab ich bis jetzt noch nichts gefunden irgendwie ist dcop erst zu 60% dokumentiert :) evtl. hat ja in der Richtung auch noch jemand eine Idee.. Gruß Andreas
Re: KDE, Env-Variablen und dcop-Programmierung
On 06.Jul 2005 - 20:31:39, Andreas Loesch wrote: Am Mittwoch, 6. Juli 2005 19:36 schrieb Andreas Pakulat: 1. Eine .xsession anlegen das soll lt. google bei kdm nicht funktionieren Nicht immer sollte man sowas glauben. Der kdm wertet $HOME/.xsession aus, wenn man die Default Sitzung startet. Sieht man auch ganz leicht wenn man mal unter /etc/X11/Xsession.d durch die Skripte schaut.. was ich gemacht habe, ein Script in /etc/X11/Xsession.d/ angelegt, dass die Variable PRINTER exportiert. Ergebnis, in einer KDE-Konsole sehe ich die Variable, auch über ein env /tmp/foo.txt im launcher bekomme ich sie zu sehen, sollte also alles funktionieren, aber bei einem Nicht unbedingt, bei beidem wird ne Shell gestartet, hast du aus der bash.bashrc wieder den Eintrag rausgenommen? $ dcop konqueror-9612 html-widget2 print true bekomme ich immer noch die gleiche Fehlermeldung, als ob die anderen Applikationen nicht die gleiche Umgebung bekommen. Nun, vllt. gehts auch einfach nicht so einfach ;-) Du solltest vllt. lieber untersuchen ob du den Drucker mittels dcop setzen kannst. dazu hab ich bis jetzt noch nichts gefunden irgendwie ist dcop erst zu 60% dokumentiert :) evtl. hat ja in der Richtung auch noch jemand eine Idee.. Nun, mit kdcop kannst du wohl die einzelnen Programme angucken, welche Funktionen sie bereitstellen. Da das im Normalfall Funktionen der API sind solltest du vllt. mal in die api-Doku gucken. Andreas -- You have a deep appreciation of the arts and music. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: KDE, Env-Variablen und dcop-Programmierung
Am Mittwoch, 6. Juli 2005 21:17 schrieb Andreas Pakulat: On 06.Jul 2005 - 20:31:39, Andreas Loesch wrote: Am Mittwoch, 6. Juli 2005 19:36 schrieb Andreas Pakulat: 1. Eine .xsession anlegen das soll lt. google bei kdm nicht funktionieren Nicht immer sollte man sowas glauben. Der kdm wertet $HOME/.xsession aus, wenn man die Default Sitzung startet. Sieht man auch ganz leicht wenn man mal unter /etc/X11/Xsession.d durch die Skripte schaut.. ja das hab ich gelesen, aber eben nur dann :) und ich hab auch User auf dieser Maschine die gnome als Default eingestellt haben, daher sollte das lieber unabhängig immer funktionieren. was ich gemacht habe, ein Script in /etc/X11/Xsession.d/ angelegt, dass die Variable PRINTER exportiert. Ergebnis, in einer KDE-Konsole sehe ich die Variable, auch über ein env /tmp/foo.txt im launcher bekomme ich sie zu sehen, sollte also alles funktionieren, aber bei einem Nicht unbedingt, bei beidem wird ne Shell gestartet, hast du aus der bash.bashrc wieder den Eintrag rausgenommen? ja und ich hab noch eine extra-Debug-Variable gesetzt.. $ dcop konqueror-9612 html-widget2 print true bekomme ich immer noch die gleiche Fehlermeldung, als ob die anderen Applikationen nicht die gleiche Umgebung bekommen. Nun, vllt. gehts auch einfach nicht so einfach ;-) hehe... Du solltest vllt. lieber untersuchen ob du den Drucker mittels dcop setzen kannst. dazu hab ich bis jetzt noch nichts gefunden irgendwie ist dcop erst zu 60% dokumentiert :) evtl. hat ja in der Richtung auch noch jemand eine Idee.. Nun, mit kdcop kannst du wohl die einzelnen Programme angucken, welche Funktionen sie bereitstellen. Da das im Normalfall Funktionen der API sind solltest du vllt. mal in die api-Doku gucken. ja, darauf wird es wohl rauslaufen, das wird dann eine größere Sache :( Danke aber für die Hilfe. Gruß Andreas
Re: [OT] Re: Linux magazine-ASSI NATURA FORA DE SÃO PAULO NÃO ENV IAM.
De uma ligada. Eles estão com problemas na distruição. Faz bastante tempo esse problema e eles não resolveram ainda, o meu caso. Hélio. - Original Message - From: Franz Gustav Niederheitmann [EMAIL PROTECTED] To: debian-user-portuguese@lists.debian.org Sent: Tuesday, November 02, 2004 3:04 PM Subject: Re: [OT] Re: Linux magazine-ASSINATURA FORA DE SÃO PAULO NÃO ENVIAM. Em Tue, 2 Nov 2004 14:54:21 -0200 (BRDT), [EMAIL PROTECTED] disse: Ola pessoal, Nao sou defensor de nenhuma das partes apenas adepto do SL. Bom vamos la, eu assinava a RL e tinha alguns contra tempos tbem mas sempre entrava em contato e recebia a mesma, tudo bem que com atraso mas vinha.Antes de atirarmos pedras deem uma olhada na revista no conteudo e bla,bla... Bom eu comprei a numero 2 e esta muito boa por sinal. é sério que els não enviam fora de sampa? sou de curitiba e assinei ela, ainda não recebi, mas acho que é porque ainda não saiu a numero 3... T+ Rodrigo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- []'s Franz Gustav Niederheitmann [EMAIL PROTECTED] GNU/LINUX USER#301744 Engenhacao da Computaria- PucPr Powered by Debian GNU/Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Global Env Variables
John Patterson wrote: So the earliest place I guess you could get it in would be to stick the export VARNAME=VALUE lines at the begining of /etc/rc.d/rc That would be fairly global. Look at the PAM configuration files (looking for something like pam_env or pam_login). Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
env|grep HZ=100
Where is the mysterious HZ=100 documented that I see in the environment of some accounts after login, and always after doing su? # env|grep HZ # su - nobody No directory, logging in with HOME=/ [EMAIL PROTECTED]:/$ env|grep HZ HZ=100 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Global Env Variables
So the earliest place I guess you could get it in would be to stick the export VARNAME=VALUE lines at the begining of /etc/rc.d/rc That would be fairly global. -Ben. I added these lines to the begining of /etc/init.d/rc: export LANG=en_GB export JAVA_HOME=/usr/lib/j2sdk1.4-sun/ but they still are not affecting the tomcat script run by rc. What am I doing wrong here? I have looked in /etc/messages and dmesg but cannot see any error messages. Any hints about where to look next? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Global Env Variables
Hi every body, I am trying to set the LANG environment variable so that when init launches my Tomcat server my web app uses the correct currency symbols. I first tried putting it in /etc/profile until I discovered that it is only sourced by login shells. So then I tried /root/.bashrc which should be sourced by non-login shells. This didn't work either. I ended up putting in in /etc/init.d/tomcat where it does work. However, this seems like a hack to me. There must be a way to set a global environment variable that is accessible to init. Thanks, John. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Global Env Variables
John Patterson wrote: Hi every body, I am trying to set the LANG environment variable so that when init launches my Tomcat server my web app uses the correct currency symbols. I first tried putting it in /etc/profile until I discovered that it is only sourced by login shells. So then I tried /root/.bashrc which should be sourced by non-login shells. This didn't work either. I ended up putting in in /etc/init.d/tomcat where it does work. However, this seems like a hack to me. There must be a way to set a global environment variable that is accessible to init. Thanks, John. The bootloader calls the kernel, the kernel calls init init calls /etc/rc.d/rc /etc/rc.d/rc calls each of the startup scripts in the runlevels. So the earliest place I guess you could get it in would be to stick the export VARNAME=VALUE lines at the begining of /etc/rc.d/rc That would be fairly global. -Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
env-update!!
Mahlzeit, ich wollte heute meine neue Maus konfigurieren, als ich feststelllen mußte, das ich dafür den Befehl env-update benötige. Könnte mir bitte einer verraten welches Debian paket ich inst. muß um den Befehl zu bekommen. Leider konnte ich durch googeln auch nichts raus bekommen. Details: Debian - unstable - 2.6.6 Danke -- -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: env-update!!
Am Mittwoch, 16. Juni 2004 17:25 schrieb Marek R.: Mahlzeit, ich wollte heute meine neue Maus konfigurieren, als ich feststelllen mußte, das ich dafür den Befehl env-update benötige. Könnte mir bitte einer verraten welches Debian paket ich inst. muß um den Befehl zu bekommen. Leider konnte ich durch googeln auch nichts raus bekommen. Du solltest auf http://packages.debian.org/ schauen. Da gibt's zwei Suchvarianten. Die zweite ist die, die du brauchst. [...] Viele Grüße Wolfgang
Re: language-env duzeltmeleri -- #250601 ve #251330
* Recai Oktas [2004-05-29 04:09:47+0300] [Bir oncekinde oldugu gibi bu iletiyi iki kere alanlardan ozur dilerim.] Merhaba, Unstable'daki perl paketlerinin guncellenmesiyle birlikte language-env (-0.56) paketinde Turkce desteginden (support.tr.pl) kaynaklanan RC (Release Criticial) bir hata olustu: #250601. Perl uzmani olmamakla beraber hatanin yazdigim perl kodunda oldugunu sanmiyorum, perl'deki bir hatanin tetiklendigini tahmin ediyorum, cunku onceki surumlerde boyle birsey yoktu. Sistemlerinde -5.8.4 surumlu perl bulunanlar bu hatadan etkilenecektir. Acilen uzerinde calisarak hatayi giderdim (#251330 nolu hata ile gonderilen yama). Paket -umarim- kisa bir sure icinde -0.57 surumuyle guncellenecektir. Tomohirosan bu sabah itibariyla yeni paketi upload etti :-) Birkac gun icinde unstable'a girer. -- roktas
language-env duzeltmeleri -- #250601 ve #251330
[Bir oncekinde oldugu gibi bu iletiyi iki kere alanlardan ozur dilerim.] Merhaba, Unstable'daki perl paketlerinin guncellenmesiyle birlikte language-env (-0.56) paketinde Turkce desteginden (support.tr.pl) kaynaklanan RC (Release Criticial) bir hata olustu: #250601. Perl uzmani olmamakla beraber hatanin yazdigim perl kodunda oldugunu sanmiyorum, perl'deki bir hatanin tetiklendigini tahmin ediyorum, cunku onceki surumlerde boyle birsey yoktu. Sistemlerinde -5.8.4 surumlu perl bulunanlar bu hatadan etkilenecektir. Acilen uzerinde calisarak hatayi giderdim (#251330 nolu hata ile gonderilen yama). Paket -umarim- kisa bir sure icinde -0.57 surumuyle guncellenecektir. -- roktas signature.asc Description: Digital signature
[language-env] bir guncelleme daha
Merhaba, UTF-8 kipli sanal konsolda kaynagini bir turlu cozemedigim, fakat -umarim ki- duzeltmis oldugum bazi sorunlar vardi. Paketi oncelikle bu duzeltmeler icin tekrar denemenizi isteyecegim. Daha once UTF-8 kipini denememis iseniz onceligi buna vermeniz uygun olur. Degisiklikler toplu halde soyle: * Konsol UTF-8 kipinde artik calismali. (Dikkat, basit bir konsol reset(1) veya echo \\033c ekrani yine allak bullak ediyor. Bu tur durumlarda trqu'da bulunan Ctrl-Alt-8 kisayolu faydali.) * uxterm bazi ayarlari kendisi yapiyor. Bu programin (aslinda bir betik) onunu kesmemek icin bir alias tanimlandi. * Butun X ucbirimlerinde (xterm, rxvt, wterm ve aterm) ayni renk temalari kullaniliyor. Aslinda renklerle ugrasmak bu paketin gorevi degil, fakat genisletilmis kipte bunlarin da eklenmesi uygun oldu. * Iletilerde bazi iyilestirmeler. * Font secimi biraz daha akilli hale getirildi. (Perl bilgimi ilerletmeye devam ediyorum :-) Eterm'u teknik nedenlerle, desteklenen X ucbirimleri listesine ekleyemiyorum. Bu program standart bir yapilandirma sistemi kullanmiyor. UTF-8 destekli olmadigindan ugrasmayi gerekli de gormuyorum. Ha aklimdayken belirteyim. Bu paketten hoslanmiyorum, bizi boyle adhoc cozumlerle ugrastirmak durumunda birakanlardan da hoslanmadigim gibi :-) P.S. Paketi yine ayni yerden, yani Alioth APT depolarindan indirebilirsiniz: wget http://l10n-turkish.alioth.debian.org/debian/language-env_0.54_all.deb dpkg -i language-env_0.54_all.deb -- roktas
Turkce destekli language-env
Merhaba, language-env paketinin Turkce destegi hazir. Paket burada yaptigim in-house testleri gecti, simdi sizin testlerinizi bekliyorum. Paketi Alioth apt arsivinden kurabilirsiniz. Apt kaynaklarini tekrar vereyim: deb http://l10n-turkish.alioth.debian.org/debian/ ./ deb-src http://l10n-turkish.alioth.debian.org/debian/ ./ Kurulum islemi malum: apt-get update apt-get install language-env Test icin fazla zamanimiz yok, en gec bu hafta Carsamba gunune kadar bu isin bitmesi lazim. Testleri tercihen Turkce ozurlu yeni kurulmus bir sistemde yapmanizi rica ediyorum. Turkceleme Woody'de calismayacaktir. Asgari sartlar X 4.3 ve console-data = 2002.12.04dbs-29. language-env Turkce destegini sistem genelinde ayarlarla degil, kullanici ev dizinindeki nokta dosyalariyla (dotfiles) yapiyor. Dolayisiyla paketi kurdugunuzda sisteminizde bir degisiklik beklemeyin :-) Bu yaklasimin bir avantaji var. Sisteminizde yeni bir kullanici olusturarak test'i o hesapta gerceklestirebilirsiniz. Turkceleme icin kurulumdan sonra su komutu kullaniyoruz: set-language-env Betik size bir dizi sual tevcih edecek. Bizim icin ozellikle onemli olan bir secenek genisletilmis ayarlar secenegi. Genisletilmis ayarlar GNU/Linux Linux ile yeni tanisan ve Turkce destegi konusunda herhangi bir fikri olmayan yeni kullanicilarin sistem genelinde yapilandirmaya girmeden sistemlerine Turkce destegi kazandirmalarini hedefliyor. Testleri sanal konsollarda ve X ucbirimlerinde (xterm, rxvt vb.) teker teker yapmanizi rica ediyorum. Paket Terminus fontu icin de destek veriyor. Sisteminizde Terminus paketleri yukluyse yapilandirma betigi bu yazitipini de hesaba katacaktir. Terminus fontlarini su paketlerle kurabilirsiniz: xfonts-terminus, console-terminus Betigin calisma sekliyle, yapilandirma adimlarinin anlasilirligi ile ilgili onerilerinizi de bekliyorum. Bu onerileri language-env alt yapisinin sundugu imkanlar dahilinde degerlendirmeye calisacagim. Paketle ilgili diger ayrintilar icin /usr/share/language-env/README.tr dosyasini okuyabilirsiniz. -- roktas
Re: Turkce destekli language-env
Debian-Installer Beta3 ile ingilizce olarak kurulum yaptığım bir sistemde, language-env ile Türkçe ISO olarak ayarları yaptığımda hiç bir sorun yaşamadım. UTF-8 ile klavyede bazı sorunlar oldu, onlara tekrar bakacağım. Asıl dikkatimi çeken, language-env ile 6. konsolda kullanıcı olarak açtığım oturum tamamen Türkçe olduğunda, daha önceden 1. konsolda root olarak açtığım oturumdaki klavye map'i de değişti. language-env ile böyle bir şey olmasını beklemiyordum. Test edecek arkadaşlar buna da dikkat edebilir mi? On Sunday 04 April 2004 09:05, Recai Oktas wrote: Merhaba, language-env paketinin Turkce destegi hazir. Paket burada yaptigim in-house testleri gecti, simdi sizin testlerinizi bekliyorum. Paketi Alioth apt arsivinden kurabilirsiniz. Apt kaynaklarini tekrar vereyim: deb http://l10n-turkish.alioth.debian.org/debian/ ./ deb-src http://l10n-turkish.alioth.debian.org/debian/ ./ Kurulum islemi malum: apt-get update apt-get install language-env Test icin fazla zamanimiz yok, en gec bu hafta Carsamba gunune kadar bu isin bitmesi lazim. Testleri tercihen Turkce ozurlu yeni kurulmus bir sistemde yapmanizi rica ediyorum. Turkceleme Woody'de calismayacaktir. Asgari sartlar X 4.3 ve console-data = 2002.12.04dbs-29. language-env Turkce destegini sistem genelinde ayarlarla degil, kullanici ev dizinindeki nokta dosyalariyla (dotfiles) yapiyor. Dolayisiyla paketi kurdugunuzda sisteminizde bir degisiklik beklemeyin :-) Bu yaklasimin bir avantaji var. Sisteminizde yeni bir kullanici olusturarak test'i o hesapta gerceklestirebilirsiniz. Turkceleme icin kurulumdan sonra su komutu kullaniyoruz: set-language-env Betik size bir dizi sual tevcih edecek. Bizim icin ozellikle onemli olan bir secenek genisletilmis ayarlar secenegi. Genisletilmis ayarlar GNU/Linux Linux ile yeni tanisan ve Turkce destegi konusunda herhangi bir fikri olmayan yeni kullanicilarin sistem genelinde yapilandirmaya girmeden sistemlerine Turkce destegi kazandirmalarini hedefliyor. Testleri sanal konsollarda ve X ucbirimlerinde (xterm, rxvt vb.) teker teker yapmanizi rica ediyorum. Paket Terminus fontu icin de destek veriyor. Sisteminizde Terminus paketleri yukluyse yapilandirma betigi bu yazitipini de hesaba katacaktir. Terminus fontlarini su paketlerle kurabilirsiniz: xfonts-terminus, console-terminus Betigin calisma sekliyle, yapilandirma adimlarinin anlasilirligi ile ilgili onerilerinizi de bekliyorum. Bu onerileri language-env alt yapisinin sundugu imkanlar dahilinde degerlendirmeye calisacagim. Paketle ilgili diger ayrintilar icin /usr/share/language-env/README.tr dosyasini okuyabilirsiniz. -- roktas
Re: Turkce destekli language-env
* Murat Demirten [2004-04-04 11:12:56+0300] Debian-Installer Beta3 ile ingilizce olarak kurulum yaptığım bir sistemde, language-env ile Türkçe ISO olarak ayarları yaptığımda hiç bir sorun yaşamadım. UTF-8 ile klavyede bazı sorunlar oldu, onlara tekrar bakacağım. UTF-8 hatasini duzelttim. Asıl dikkatimi çeken, language-env ile 6. konsolda kullanıcı olarak açtığım oturum tamamen Türkçe olduğunda, daha önceden 1. konsolda root olarak açtığım oturumdaki klavye map'i de değişti. language-env ile böyle bir şey olmasını beklemiyordum. Test edecek arkadaşlar buna da dikkat edebilir mi? Maalesef bu konu Linux sanal konsol arayuzuyle ilgili bir yetersizlik (ve bazilarina gore de guvenlik acigi). Yazitipini veya belirli klavye ozelliklerini (led'ler vesaire) per tty yapabiliyoruz, fakat tuseslemi butun vt'ler arasinda ortak kullaniliyor. -- roktas
Re: Turkce destekli language-env
On Sun, 4 Apr 2004 09:05:53 +0300, Recai Oktas [EMAIL PROTECTED] wrote:
Merhaba,
language-env paketinin Turkce destegi hazir. Paket burada yaptigim
in-house testleri gecti, simdi sizin testlerinizi bekliyorum. Paketi
Alioth apt arsivinden kurabilirsiniz. Apt kaynaklarini tekrar vereyim:
deb http://l10n-turkish.alioth.debian.org/debian/ ./
deb-src http://l10n-turkish.alioth.debian.org/debian/ ./
Kurulum islemi malum:
apt-get update apt-get install language-env
Test icin fazla zamanimiz yok, en gec bu hafta Carsamba gunune kadar bu
isin bitmesi lazim.
Testleri tercihen Turkce ozurlu yeni kurulmus bir sistemde yapmanizi
rica ediyorum. Turkceleme Woody'de calismayacaktir. Asgari sartlar X
4.3 ve console-data = 2002.12.04dbs-29.
language-env Turkce destegini sistem genelinde ayarlarla degil,
kullanici ev dizinindeki nokta dosyalariyla (dotfiles) yapiyor.
Dolayisiyla paketi kurdugunuzda sisteminizde bir degisiklik beklemeyin
:-) Bu yaklasimin bir avantaji var. Sisteminizde yeni bir kullanici
olusturarak test'i o hesapta gerceklestirebilirsiniz. Turkceleme icin
kurulumdan sonra su komutu kullaniyoruz:
set-language-env
Betik size bir dizi sual tevcih edecek. Bizim icin ozellikle onemli
olan bir secenek genisletilmis ayarlar secenegi. Genisletilmis
ayarlar GNU/Linux Linux ile yeni tanisan ve Turkce destegi konusunda
herhangi bir fikri olmayan yeni kullanicilarin sistem genelinde
yapilandirmaya girmeden sistemlerine Turkce destegi kazandirmalarini
hedefliyor.
Testleri sanal konsollarda ve X ucbirimlerinde (xterm, rxvt vb.) teker
teker yapmanizi rica ediyorum. Paket Terminus fontu icin de destek
veriyor. Sisteminizde Terminus paketleri yukluyse yapilandirma betigi
bu yazitipini de hesaba katacaktir. Terminus fontlarini su paketlerle
kurabilirsiniz: xfonts-terminus, console-terminus
Betigin calisma sekliyle, yapilandirma adimlarinin anlasilirligi ile
ilgili onerilerinizi de bekliyorum. Bu onerileri language-env alt
yapisinin sundugu imkanlar dahilinde degerlendirmeye calisacagim.
Paketle ilgili diger ayrintilar icin /usr/share/language-env/README.tr
dosyasini okuyabilirsiniz.
Selamlar,
Sid altında KDE 3.2 kullanıyorum, sistem yereli iso-8859-9 .*Bu sisteme
daha önce hiç bir Türkçeleştirme girişiminde bulunmamıştım* KDE üzerinde
pek sorunum yoktu zaten. Ancak xterm'de Türkçe karakterleri basamıyordum.
Paket kurulumu sonrasında bu sorun ortan kalktı. Konsolda da sorunlar
vardı onlar da artık tarih oldu gibi. Şimdilik tek sorunum bir türlü
çözemediğim gtk uygulamalarındaki aşırı küçük yazı tipi boyutu
/etc/gtk/gtkrc dosyasındaki font boyutlarını 12'den 18'e yükselttim ancak
birşey değişmedi.
dosyanın içeriği aşağıda
--
style gtk-default-tr {
fontset = -*-verdana-medium-r-normal--18-*-*-*-*-*-iso8859-9,
-*-arial-medium-r-normal--18-*-*-*-*-*-iso8859-9,
-*-helvetica-medium-r-normal--18-*-*-*-*-*-iso8859-9,
-*-arial-medium-r-normal--18-*-*-*-*-*-iso8859-9,*-r-*
}
class GtkWidget style gtk-default-tr
--
XF86Config-4'de 100dpi'lık fontları üste aldım yine sorun çözülmedi.
ilgili ekran görüntüsü : http://www.sonsuzdongu.com/dosyalar/gtk_font.jpg
En Türkçe dağıtım olma yolunda verdiğiniz bu savaştan dolayı da sizleri
tebrik ederim ;)
Kolay gelsin
Re: Turkce destekli language-env
On Sun, 04 Apr 2004 12:06:12 +0300, Osman Yüksel [EMAIL PROTECTED]
wrote:
On Sun, 4 Apr 2004 09:05:53 +0300, Recai Oktas [EMAIL PROTECTED] wrote:
Merhaba,
language-env paketinin Turkce destegi hazir. Paket burada yaptigim
in-house testleri gecti, simdi sizin testlerinizi bekliyorum. Paketi
Alioth apt arsivinden kurabilirsiniz. Apt kaynaklarini tekrar vereyim:
deb http://l10n-turkish.alioth.debian.org/debian/ ./
deb-src http://l10n-turkish.alioth.debian.org/debian/ ./
Kurulum islemi malum:
apt-get update apt-get install language-env
Test icin fazla zamanimiz yok, en gec bu hafta Carsamba gunune kadar bu
isin bitmesi lazim.
Testleri tercihen Turkce ozurlu yeni kurulmus bir sistemde yapmanizi
rica ediyorum. Turkceleme Woody'de calismayacaktir. Asgari sartlar X
4.3 ve console-data = 2002.12.04dbs-29.
language-env Turkce destegini sistem genelinde ayarlarla degil,
kullanici ev dizinindeki nokta dosyalariyla (dotfiles) yapiyor.
Dolayisiyla paketi kurdugunuzda sisteminizde bir degisiklik beklemeyin
:-) Bu yaklasimin bir avantaji var. Sisteminizde yeni bir kullanici
olusturarak test'i o hesapta gerceklestirebilirsiniz. Turkceleme icin
kurulumdan sonra su komutu kullaniyoruz:
set-language-env
Betik size bir dizi sual tevcih edecek. Bizim icin ozellikle onemli
olan bir secenek genisletilmis ayarlar secenegi. Genisletilmis
ayarlar GNU/Linux Linux ile yeni tanisan ve Turkce destegi konusunda
herhangi bir fikri olmayan yeni kullanicilarin sistem genelinde
yapilandirmaya girmeden sistemlerine Turkce destegi kazandirmalarini
hedefliyor.
Testleri sanal konsollarda ve X ucbirimlerinde (xterm, rxvt vb.) teker
teker yapmanizi rica ediyorum. Paket Terminus fontu icin de destek
veriyor. Sisteminizde Terminus paketleri yukluyse yapilandirma betigi
bu yazitipini de hesaba katacaktir. Terminus fontlarini su paketlerle
kurabilirsiniz: xfonts-terminus, console-terminus
Betigin calisma sekliyle, yapilandirma adimlarinin anlasilirligi ile
ilgili onerilerinizi de bekliyorum. Bu onerileri language-env alt
yapisinin sundugu imkanlar dahilinde degerlendirmeye calisacagim.
Paketle ilgili diger ayrintilar icin /usr/share/language-env/README.tr
dosyasini okuyabilirsiniz.
Selamlar,
Sid altında KDE 3.2 kullanıyorum, sistem yereli iso-8859-9 .*Bu sisteme
daha önce hiç bir Türkçeleştirme girişiminde bulunmamıştım* KDE üzerinde
pek sorunum yoktu zaten. Ancak xterm'de Türkçe karakterleri
basamıyordum. Paket kurulumu sonrasında bu sorun ortan kalktı. Konsolda
da sorunlar vardı onlar da artık tarih oldu gibi. Şimdilik tek sorunum
bir türlü çözemediğim gtk uygulamalarındaki aşırı küçük yazı tipi boyutu
/etc/gtk/gtkrc dosyasındaki font boyutlarını 12'den 18'e yükselttim
ancak birşey değişmedi.
dosyanın içeriği aşağıda
--
style gtk-default-tr {
fontset = -*-verdana-medium-r-normal--18-*-*-*-*-*-iso8859-9,
-*-arial-medium-r-normal--18-*-*-*-*-*-iso8859-9,
-*-helvetica-medium-r-normal--18-*-*-*-*-*-iso8859-9,
-*-arial-medium-r-normal--18-*-*-*-*-*-iso8859-9,*-r-*
}
class GtkWidget style gtk-default-tr
--
XF86Config-4'de 100dpi'lık fontları üste aldım yine sorun çözülmedi.
ilgili ekran görüntüsü : http://www.sonsuzdongu.com/dosyalar/gtk_font.jpg
En Türkçe dağıtım olma yolunda verdiğiniz bu savaştan dolayı da sizleri
tebrik ederim ;)
Kolay gelsin
Sorun XF86Config-4'deki fontpath'den kaynaklanıyormuş, şimdi sorunu çözdüm
, teşekkürler :)
Re: /etc/profile and setting env variables
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: I want to do this for all users on the system, so I thought: edit /etc/profile I did that... but it doesn't seem to make a difference, and worse, /etc/profile seems to get nuked upon logout/login. So clearly I am doing this in the wrong place. /etc/profile is not supposed to be deleted automatically. Something is wrong in your system installation. Who knows which other files also get nuked -- /etc/passwd perhaps? You can see that the situation needs to be corrected. /etc/profile is only read for Bourne-ish shells, AFAIK. C-ish shells read /etc/csh.login, and zsh reads /etc/zprofile and /etc/zlogin, amongst othes. Kai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /etc/profile and setting env variables
On Sun, Mar 21, 2004 at 09:56:57PM -0500, [EMAIL PROTECTED] wrote: Here's my questions: a) Where do I edit global profile changes? One place for enviroment variables is with pam_env in /etc/pam.d and /etc/security. Another for enviroment variables is /etc/enviroment Limits can be handled with pam_limit b) I looked at the .profile and the .bashrc files in my user directories... I may be an idiot, but I don't see where they are in turn calling a global profile file... or is it the other way around (a global file is calling them?) The shell automatically reads them. What it reads is dependant on whether it is a login shell, an interactive shell and the output of 'pom' :-) Thanks for suggestions and help I tried Google and the list archives, but I can't seem to formulate a good search that gets me the info I need. Try 'man bash'. Its under INVOCATION. Don't ask me if X parses /etc/profile etc. 'man X' maybe? Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
/etc/profile and setting env variables
I am trying to set two specific environment variables (I'm installing Sun Java) and I need to append a path to the PATH variable and also create a new environment variable. The problem is, however: I have no idea WHERE to do this. I want to do this for all users on the system, so I thought: edit /etc/profile I did that... but it doesn't seem to make a difference, and worse, /etc/profile seems to get nuked upon logout/login. So clearly I am doing this in the wrong place. Here's my questions: a) Where do I edit global profile changes? b) I looked at the .profile and the .bashrc files in my user directories... I may be an idiot, but I don't see where they are in turn calling a global profile file... or is it the other way around (a global file is calling them?) Thanks for suggestions and help I tried Google and the list archives, but I can't seem to formulate a good search that gets me the info I need. Moe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
set-language-env and utf-8
Hello, for those who didn't follow the previous thread... I need most locales set to de_DE.UTF-8 -- however, I don't want system messages to be in german. The nice tool set-language-env offers merely the choice between iso-8859-1 or -15; I tried following the changes it made and replace them with utf-8, however, this doesn't seem to be all that easy. At any rate, I don't get the desired result. Trying to do it on my own, I got lost. I changed both ~/.xsession and ~/.bashrc ... well, at any rate things now work when I start the applications from an xterm window. They still garble my text when I launch them from the menu bar. Where does one set all the LC_WHATEVER locales to make them stick? I tried grep'ping my home dir in the hope to find more files, but all hits I got were in my mailbox and mozilla's cache. cu, Schnobs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: set-language-env and utf-8
On Thu, Feb 05, 2004 at 09:59:42PM +0100, Christian Schnobrich wrote: Where does one set all the LC_WHATEVER locales to make them stick? I From my ~/.profile: LANG=be_BY.UTF-8 LC_MESSAGES=C -- Be happy! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
