Technical discussions | Discussions techniques
Guest, Saturday 08 June 2013 à 01:13
|
|
|
Hello,
I'm trying to start developing an applet in bash. I started with the demo_bash script from bzr, but when I get the following errors:
When it loads:
./demo_bash.sh: line 94: echo: write error: Broken pipe
./demo_bash.sh: line 95: echo: write error: Broken pipe
./demo_bash.sh: line 96: echo: write error: Broken pipe
./demo_bash.sh: line 97: echo: write error: Broken pipe
On click:
./demo_bash.sh: line 114: echo: write error: Broken pipe
./demo_bash.sh: line 115: echo: write error: Broken pipe
./demo_bash.sh: line 116: echo: write error: Broken pipe
I'm running Cairo-Dock 3.2.1 on Xubuntu 13.04.
Cheers! |
matttbe, Saturday 08 June 2013 à 14:22
|
|
Subscription date : 24 January 2009
Messages : 12573
|
Hello and thank you for this bug report!
Yes, this error is "normal" because "os.popen" is no longer used with 'read()' and then 'echo' is no longer redirected to stdout.
I modified it on BZR by using subprocess.call("...", shell=True) it should be more appropriated I think.
@fabounet: can you confirm? (subprocess)
@Guest: can you confirm that it's better by applying this patch to this file: /usr/lib/python2.7/dist-packages/CDBashApplet.py
--- /usr/lib/python2.7/dist-packages/CDBashApplet.py 2013-03-22 11:20:18 +0000
+++ /usr/lib/python2.7/dist-packages/CDBashApplet.py 2013-06-08 11:56:58 +0000
@@ -17,6 +17,7 @@
import os.path
+import subprocess
from CDApplet import CDApplet
@@ -31,7 +32,7 @@
def call(self,action):
- os.popen("cd " + self.app_folder + " && ./" + self.cAppletName + ".sh " + self.cAppletName + " " + self.cBusPath + " " + self.cConfFile + " " + self.cParentAppName + " " + action)
+ subprocess.call("cd " + self.app_folder + " && ./" + self.cAppletName + ".sh " + self.cAppletName + " " + self.cBusPath + " " + self.cConfFile + " " + self.cParentAppName + " " + action, shell=True)
(simply add "import subprocess" at the beginning and replaced "os.popen" by "subprocess.call" and add ", shell=True)" at the end of this line. |
Subscription date : 30 November 2007
Messages : 17118
|
or maybe "subprocess.check_output" if we want to have the outputs of the bash script ?
anyway both will call popen |
matttbe, Monday 10 June 2013 à 17:54
|
|
Subscription date : 24 January 2009
Messages : 12573
|
or maybe "subprocess.check_output" if we want to have the outputs of the bash script ? No because it's mostly to check if the return code is zero: If the return code was zero then return, otherwise raise CalledProcessError. The CalledProcessError object will have the return code in the returncode attribute. (no need a new exception if there is a problem with the script
The most problem I see is this warning: Warning
Invoking the system shell with shell=True can be a security hazard if combined with untrusted input. See the warning under Frequently Used Arguments for details.
Executing shell commands that incorporate unsanitized input from an untrusted source makes a program vulnerable to shell injection, a serious security flaw which can result in arbitrary command execution. For this reason, the use of shell=True is strongly discouraged in cases where the command string is constructed from external input: >>> from subprocess import call
>>> filename = input("What file would you like to display?\n")
What file would you like to display?
non_existent; rm -rf / #
>>> call("cat " + filename, shell=True) # Uh-oh. This will end badly...
shell=False disables all shell based features, but does not suffer from this vulnerability; see the Note in the Popen constructor documentation for helpful hints in getting shell=False to work.
When using shell=True, pipes.quote() can be used to properly escape whitespace and shell metacharacters in strings that are going to be used to construct shell commands.
But it's exactly what we want I think. |
Subscription date : 30 November 2007
Messages : 17118
|
well, I think we can trust our own applets |
matttbe, Monday 17 June 2013 à 14:44
|
|
Subscription date : 24 January 2009
Messages : 12573
|
|
Technical discussions | Discussions techniques
|