469,609 Members | 1,634 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,609 developers. It's quick & easy.

Python Nautilus script

Hi,

I'm trying to write a python script for Nautilus.
To get the list of files selected in the Nautilus right pane, you use
the $NAUTILUS_SCRIPT_SELECTED_FILE_PATHS environment variable which is
normally available to the script. Actually, it works with bash scripts
but not with python scripts

import os
files = os.environ['NAUTILUS_SCRIPT_SELECTED_FILE_PATHS'].splitlines()

gives a:

File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/UserDict.py", line 22, in __getitem__
raise KeyError(key)
KeyError: 'NAUTILUS_SCRIPT_SELECTED_FILE_PATHS'

Fredrik Lundh explained me that all environment variables are not
accessible from subprocesses of an application.

So my question is how can I get the Nautilus selected files in a python
script?

Thanks,
Michel
--
Michel Leunen
http://linux.leunen.com
Sep 15 '08 #1
10 3229
Michel Leunen schrieb:
Hi,

I'm trying to write a python script for Nautilus.
To get the list of files selected in the Nautilus right pane, you use
the $NAUTILUS_SCRIPT_SELECTED_FILE_PATHS environment variable which is
normally available to the script. Actually, it works with bash scripts
but not with python scripts

import os
files = os.environ['NAUTILUS_SCRIPT_SELECTED_FILE_PATHS'].splitlines()

gives a:

File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/UserDict.py", line 22, in __getitem__
raise KeyError(key)
KeyError: 'NAUTILUS_SCRIPT_SELECTED_FILE_PATHS'

Fredrik Lundh explained me that all environment variables are not
accessible from subprocesses of an application.

So my question is how can I get the Nautilus selected files in a python
script?
There shouldn't be a difference between a shell-script and a
python-script. Environment-variables are a unix-process-thing, and thus
the rules that govern them apply to *all* processes - the shell is one
of these, there is nothing special to it.

If the shell-script gets the variable, the python-script will as well.

Are you sure the shell gets the value? Or is it just silently ignoring a
missing value, and the python-script isn't? According to the docs (I
only googled the variable-name), the variable seems only to be set "only
if local"[1], whatever that means.

https://help.ubuntu.com/community/NautilusScriptsHowto

Diez

Sep 15 '08 #2
Diez B. Roggisch a écrit :
There shouldn't be a difference between a shell-script and a
python-script. Environment-variables are a unix-process-thing, and thus
the rules that govern them apply to *all* processes - the shell is one
of these, there is nothing special to it.

If the shell-script gets the variable, the python-script will as well.
Yes, that's what I thought too but try this: open a terminal and type

$ echo $HOSTNAME

you will get the name of your computer.
Now try this instead:

$ python
>>import os
os.environ['HOSTNAME']
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/UserDict.py", line 22, in __getitem__
raise KeyError(key)
KeyError: 'HOSTNAME'
>>>
It appears that's because HOSTNAME is not exported.
But in the case of Nautilus script, how to workaround this issue?

--
Michel Leunen
http://linux.leunen.com
Sep 15 '08 #3
Michel Leunen schrieb:
Diez B. Roggisch a écrit :
>There shouldn't be a difference between a shell-script and a
python-script. Environment-variables are a unix-process-thing, and
thus the rules that govern them apply to *all* processes - the shell
is one of these, there is nothing special to it.

If the shell-script gets the variable, the python-script will as well.

Yes, that's what I thought too but try this: open a terminal and type

$ echo $HOSTNAME

you will get the name of your computer.
Now try this instead:

$ python
>>import os
>>os.environ['HOSTNAME']
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/UserDict.py", line 22, in __getitem__
raise KeyError(key)
KeyError: 'HOSTNAME'
>>>
Which is the exact right thing to happen if the HOSTNAME is not exported.

The echo above is executed IN THE CURRENT SHELL environment. If it
weren't - why would there be any distinction between local and exported
variables at all?

If you put

It appears that's because HOSTNAME is not exported.
But in the case of Nautilus script, how to workaround this issue?
I don't know for sure if the shell has something build-in that makes it
spawn shell-subprocesses with a different environment than other processes.

However, if you want you can do something like this:

#!/bin/bash
export VARIABLE_NAME
python /the/python/script.py

You create a shell-script that exports the environment first, and then
invokes python.

Diez
Sep 15 '08 #4
Diez B. Roggisch a écrit :
However, if you want you can do something like this:

#!/bin/bash
export VARIABLE_NAME
python /the/python/script.py

You create a shell-script that exports the environment first, and then
invokes python.
Oh, that's a good idea, I'll try this.
Thanks

--
Michel Leunen
http://linux.leunen.com
Sep 15 '08 #5
On Mon, 2008-09-15 at 22:00 +0200, Diez B. Roggisch wrote:
Michel Leunen schrieb:
Diez B. Roggisch a écrit :
There shouldn't be a difference between a shell-script and a
python-script. Environment-variables are a unix-process-thing, and
thus the rules that govern them apply to *all* processes - the shell
is one of these, there is nothing special to it.

If the shell-script gets the variable, the python-script will as well.
Yes, that's what I thought too but try this: open a terminal and type

$ echo $HOSTNAME

you will get the name of your computer.
Now try this instead:

$ python
>>import os
>>os.environ['HOSTNAME']
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/UserDict.py", line 22, in __getitem__
raise KeyError(key)
KeyError: 'HOSTNAME'
>>>

Which is the exact right thing to happen if the HOSTNAME is not exported.

The echo above is executed IN THE CURRENT SHELL environment. If it
weren't - why would there be any distinction between local and exported
variables at all?

If you put

It appears that's because HOSTNAME is not exported.
But in the case of Nautilus script, how to workaround this issue?

I don't know for sure if the shell has something build-in that makes it
spawn shell-subprocesses with a different environment than other processes.

However, if you want you can do something like this:

#!/bin/bash
export VARIABLE_NAME
python /the/python/script.py

You create a shell-script that exports the environment first, and then
invokes python.

Diez
--
Alternatively, export the variable when you create it, in .bashrc or
wherever it is getting created. That's probably the Right Thing to
Do(tm) in this case.

Cheers,
Cliff

Sep 15 '08 #6
>>It appears that's because HOSTNAME is not exported.
>>But in the case of Nautilus script, how to workaround this issue?

Alternatively, export the variable when you create it, in .bashrc or
wherever it is getting created. That's probably the Right Thing to
Do(tm) in this case.

Certainly not, as the OP uses a network monitoring software called
Nautilus - and that communicates state to subprocesses using environment
variables. Nothing to do with .bashrc.

Diez
Sep 15 '08 #7
On Mon, Sep 15, 2008 at 2:00 PM, Diez B. Roggisch <de***@nospam.web.dewrote:
>>>It appears that's because HOSTNAME is not exported.
But in the case of Nautilus script, how to workaround this issue?

Alternatively, export the variable when you create it, in .bashrc or
wherever it is getting created. That's probably the Right Thing to
Do(tm) in this case.


Certainly not, as the OP uses a network monitoring software called Nautilus
- and that communicates state to subprocesses using environment variables.
Nothing to do with .bashrc.
Just to clarify, the OP is talking about Nautilus as in the GNOME file
manager, not some network monitor.
- Chris
>
Diez
--
http://mail.python.org/mailman/listinfo/python-list


--
Follow the path of the Iguana...
http://rebertia.com
Sep 15 '08 #8
Chris Rebert schrieb:
On Mon, Sep 15, 2008 at 2:00 PM, Diez B. Roggisch <de***@nospam.web.dewrote:
>>>>It appears that's because HOSTNAME is not exported.
But in the case of Nautilus script, how to workaround this issue?
Alternatively, export the variable when you create it, in .bashrc or
wherever it is getting created. That's probably the Right Thing to
Do(tm) in this case.

Certainly not, as the OP uses a network monitoring software called Nautilus
- and that communicates state to subprocesses using environment variables.
Nothing to do with .bashrc.

Just to clarify, the OP is talking about Nautilus as in the GNOME file
manager, not some network monitor.
Erm, yep - I confused that with Nagios. Please don't ask me why.

The point stands though - .bashrc has nothing to do with that.

Diez
Sep 15 '08 #9
On 15 sep, 21:46, Michel Leunen <mic...@nospam.pleasewrote:
>
But in the case of Nautilus script, how to workaround this issue?

--
Michel Leunen
http://linux.leunen.com
I don't have that issue.
This script works as expected:
---------------
#! /usr/bin/python
# -*- coding: utf8 -*-

import os, sys

#NAUTILUS_SCRIPT_SELECTED_FILE_PATHS : chemins des fichiers
sélectionnés séparés par des retours à la ligne (newline) (uniquement
pour les fichiers locaux)
#NAUTILUS_SCRIPT_SELECTED_URIS : URIs des fichiers sélectionnés
séparés par des retours à la ligne (newline)
#NAUTILUS_SCRIPT_CURRENT_URI : URI de l'emplacement actuel
#NAUTILUS_SCRIPT_WINDOW_GEOMETRY : position et taille de la fenêtre
actuelle
KEYS=("NAUTILUS_SCRIPT_SELECTED_FILE_PATHS",
"NAUTILUS_SCRIPT_SELECTED_URIS", "NAUTILUS_SCRIPT_CURRENT_URI",
"NAUTILUS_SCRIPT_WINDOW_GEOMETRY")

ft=open("/home/kaer/stupid.txt", "w")
for key_value in [(key, os.environ.get(key, 'NOT FOUND')) for key in
KEYS]:
ft.write("env(%s): %s\n" % key_value)
file_names=sys.argv[1:]
for index, file_name in enumerate(file_names):
ft.write("%s: [%s]\n" % (index, file_name))
if os.path.isfile(file_name): os.rename(file_name, '%03d-%s' %
(index+1, file_name))
ft.close()
---------------
I selected 3 files (created on purpose) in Nautilus.
Those files where renamed and stupid.txt created with that content:
---------------
env(NAUTILUS_SCRIPT_SELECTED_FILE_PATHS): /home/kaer/baz
/home/kaer/bar
/home/kaer/foo

env(NAUTILUS_SCRIPT_SELECTED_URIS): file:///home/kaer/baz
file:///home/kaer/bar
file:///home/kaer/foo

env(NAUTILUS_SCRIPT_CURRENT_URI): file:///home/kaer
env(NAUTILUS_SCRIPT_WINDOW_GEOMETRY): 1280x885+0+25
0: [baz]
1: [bar]
2: [foo]
---------------
You can as well use sys.argv[1:] that will give you the list of
selected files.

Hope that helps.
Sep 15 '08 #10
kaer a écrit :
#! /usr/bin/python
# -*- coding: utf8 -*-

import os, sys

#NAUTILUS_SCRIPT_SELECTED_FILE_PATHS : chemins des fichiers
sélectionnés séparés par des retours à la ligne (newline) (uniquement
pour les fichiers locaux)
#NAUTILUS_SCRIPT_SELECTED_URIS : URIs des fichiers sélectionnés
séparés par des retours à la ligne (newline)
#NAUTILUS_SCRIPT_CURRENT_URI : URI de l'emplacement actuel
#NAUTILUS_SCRIPT_WINDOW_GEOMETRY : position et taille de la fenêtre
actuelle
KEYS=("NAUTILUS_SCRIPT_SELECTED_FILE_PATHS",
"NAUTILUS_SCRIPT_SELECTED_URIS", "NAUTILUS_SCRIPT_CURRENT_URI",
"NAUTILUS_SCRIPT_WINDOW_GEOMETRY")

ft=open("/home/kaer/stupid.txt", "w")
for key_value in [(key, os.environ.get(key, 'NOT FOUND')) for key in
KEYS]:
ft.write("env(%s): %s\n" % key_value)
file_names=sys.argv[1:]
for index, file_name in enumerate(file_names):
ft.write("%s: [%s]\n" % (index, file_name))
if os.path.isfile(file_name): os.rename(file_name, '%03d-%s' %
(index+1, file_name))
ft.close()
Yes, indeed, it works with your code. Thanks for it.
I just have to find out why it doesn't work with mine. The problem is
that Nautilus scripts are hard to debug.

Thanks for your help,
Michel

--
Michel Leunen
http://linux.leunen.com
Sep 16 '08 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

28 posts views Thread by Erik Johnson | last post: by
2 posts views Thread by DeepBleu | last post: by
52 posts views Thread by Olivier Scalbert | last post: by
17 posts views Thread by Paul Rubin | last post: by
47 posts views Thread by Kenneth McDonald | last post: by
6 posts views Thread by tatamata | last post: by
7 posts views Thread by pankajit09 | last post: by
reply views Thread by devrayhaan | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.