Hi David. Unfortunately it's more than just $DISPLAY that's involved. These days, X is a bit more cautious about who is authorised to access the display. You don't want any user of your PC (or other external users) to have unfettered access to your screen. You could try adding "XAUTHORITY=/home/dz/.Xauthority" to your script to define the appropriate "MIT-MAGIC-COOKIE". This means of course that if you happen to be logged in as a different user, the script won't work because the cookie would not match that being used by the current user. I just tried it here at the office, and it seems to do the trick. (man xauth) I hope this works for you. Regards, Morrie. -----Original Message----- From: David Zuccaro [mailto:david.zuccaro@optusnet.com.au] Sent: Thursday, 22 December 2016 7:13 PM To: Morrie Wyatt; luv-main@luv.asn.au Subject: Re: Every 2 Minutes cronjob On 22/12/16 18:57, Morrie Wyatt via luv-main wrote:

Or add "> /tmp/scap.debug 2>&1" to the end of your crontab line to capture any outout and error messages.

I captured the error output and got:

No protocol specified giblib error: Can't open X display. It *is* running, yeah?

This is what scap does: #!/bin/sh DISPLAY=:0 /usr/bin/scrot 'scap-%Y-%m-%d-%H:%M.jpg' -q 70 -e 'mv $f /home/dz/shots/; chown dz.dz /home/dz/shots/$f' > /tmp/scap.debug 2>&1 Yes it's a screen capture script. Am I setting DISPLAY properly? Thanks David

On Fri, Dec 23, 2016 at 12:57:48AM +1100, Andrew McGlashan wrote:

#!/usr/bin/env bash

please don't promote thet obnoxious brain-damage. it's bad enough seeing the #!/usr/bin/env disease on sites like stackexchange (where at least they have the excuse of catering to non-linux systems - and even there it's broken, because env isn't guaranteed to be in /usr/bin on all systems anyway) but bash will be /bin/bash on every linux system that exists, and always will be. there are lots of good reasons why abusing /usr/bin/env like this is a bad idea at: http://unix.stackexchange.com/questions/29608/why-is-it-better-to-use-usr-bi... (see also the Linked and Related Q&As on the RHS of the page) the one argument in favour of doing this (that the script will be run by the first matching interpreter found in the PATH) is both a blessing and a curse. at best it's a minor convenience. at worst, it's a potential security risk - it's not an accident or an oversight that every unix system since the #! line was invented DOESN'T search $PATH for the interpreter. one of the worst problems with doing it is that it breaks the ability to pass command-line options to the interpreter in the #! line - e.g. '#!/bin/bash -e' works, but with '#!/usr/bin/env bash -e' the '-e' is ignored by bash. this is bad enough for bash, but worse for other scripting languages where passing command-line options to the #! interpreter is routine (like sed, awk, perl) or required (like make, which requires '-f' on the #! line of an executable make script). also, env messes with ARGV[0] which can make the script difficult or impossible to find with ps '#!/usr/bin/env interpreter' - brought to you by the people who think that 'curl http://randomwebsite/path/to/script | sudo bash' is a good way to install software. craig -- craig sanders <cas@taz.net.au>

On Fri, Dec 23, 2016 at 01:37:11AM +1100, Craig Sanders wrote:

one of the worst problems with doing it is that it breaks the ability to pass command-line options to the interpreter in the #! line - e.g. '#!/bin/bash -e' works, but with '#!/usr/bin/env bash -e' the '-e' is ignored by bash.

that's not quite true. it's not that bash ignores the '-e', it's that env tries to run a non-existent program called 'bash -e' e.g. $ cat foo.bash #!/usr/bin/env bash -e echo foo $ ./foo.bash /usr/bin/env: ‘bash -e’: No such file or directory IMO, that's an unmistakable signal that env was not intended to be used in this way. IIRC some versions of env (not the one in GNU coreutils, which is installed on almost every linux system - with some embedded or busybox/tinybox systems being the exceptions) will still run the correct interpreter but fails to pass on any options. craig -- craig sanders <cas@taz.net.au>

On Fri, Dec 23, 2016 at 02:35:06PM +1100, Russell Coker wrote:

Putting the -e in the first line of the shell script is considered bad practice anyway.

that's debatable. some think it's bad practice. some think it's using bash as it's documented to work. 'bash -e' was just a simple example (and it's easy enough to just have 'set -e' in the script itself), not the beginning or end of the problem. As mentioned, the problem is even worse if used with other languages. e.g the following perl script works and produces useful (and expected) output: #!/usr/bin/perl -p s/foo/bar/; This doesn't: #!/usr/bin/perl s/foo/bar/; for those not familiar with perl, `-p` tells perl to wrap the entire script (aside from a few exclusions like BEGIN and END blocks) in a while/read/print loop on STDIN+filename args, so the former script actually runs as if the code is more like this (slightly simplified): #!/usr/bin/perl while (<>) { s/foo/bar/; print "$_"; } see `man perlrun` for more details. and note that it gets even more complicated when other options are also used - e.g. see the example given for '#!/usr/bin/perl -pi.orig'

If correct operation of the script requires aborting on error then you don't want someone debugging it with "bash -x scriptname" to accidentally stop that.

as with most things, there are pros and cons to that. sometimes you want -x to override -e, sometimes you don't. and you can always "override the override" by running 'bash -x -e scriptname' the point is that #!/usr/bin/env breaks the documented behaviour of interpreters, preventing scripts from being run with any options that they may require. craig -- craig sanders <cas@taz.net.au>

On Fri, Dec 23, 2016 at 06:02:54PM +1100, russell@coker.com.au wrote:

While it is documented to work that way doesn't mean it's a good idea to do it.

the issue isn't about bash and '-e', it's about env breaking the ability to pass options on the #! line. '-e' is just a trivial illustrative example. with bash it's only a minor annoyance because most (or maybe all, i can't remember) options can be enabled with a 'set' command inside the script anyway. For other languages, it can break the script entirely or, worse, change the script's behaviour in subtle and "interesting" ways.

cd $DIR rm -rf *

-e isn't a replacement for defensive programming around potentially dangerous things, it's just a way to avoid uglifying your code by adding exit-status checks after every trivial command. an uncaught non-zero exit code will abort the script. a saner, or more defensive, way to write that would be: cd "$DIR" && rm -rf * or cd "$DIR" \ && rm -rf * \ || exit 1 and it's worthwhile doing that (including quoting the $DIR variable) whether you use 'bash -e', 'set -e' in the script, or neither. craig -- craig sanders <cas@taz.net.au>

On Fri, Dec 23, 2016 at 08:11:15AM +1100, Sean Crosby wrote:

I've taken to using /usr/bin/env a bit more because of the max length limit in shebang lines. We store newer versions of Ruby, Python etc on a separate filesystem, where there are many versions of these directories, and they are hidden down quite far in the dirtree. So we regularly hit the max shebang length limit of 128 characters.

that's one of the things that symlinks are for. e.g. I have python2.6, 2.7, 3.1, 3.2, 3.4, and 3.5 all installed in /usr/bin, with symlinks python & python2 pointing to 2.7, and python3 pointing to 3.5 that's all managed automatically by the system python packages. if i ever need a custom compiled python 3.x or whatever, I can either make a package the same way or install it under /usr/local and create and/or update the symlink as needed. or i can compile and install it anywhere and make a specific symlink (e.g. /usr/local/bin/python.custom) pointing to it - avoiding the 128 character #! limit. python scripts have either a specific versioned binary name in the #! line or just #!/usr/bin/python or #!/usr/bin/python2 for the latest python 2.x or #!/usr/bin/python3 for the latest python 3.x. at some point in the future, python3 will become the default python and /usr/bin/python will point to it. and the scripts work exactly the same, using the exact same interpreter (with the exact same set of library modules) no matter who runs them or what environment they're run in (e.g. from a shell, or from cron, or a web server). Consistency and predictability are important. As is manual control/override where needed. similarly, I have ruby1.9.1, ruby2.0, ruby2.1, ruby2.2, and ruby2.3 in /usr/bin, with /usr/bin/ruby a symlink pointing to ruby2.3 craig ps: to me, using #!/usr/bin/env is just a variant of something that i've hated ever since my first unix sysadmin job (actually, before that when I was just a user or programmer) - important things should not be buried in a programmer's home directory and dependent on their idiosyncratic (and undocumented) environment settings. that's fine for your own tools and hacks and dev/testing versions, but when any such program moves beyond being a personal tool, it needs to be integrated into the system so that it works consistently for everyone who uses it. -- craig sanders <cas@taz.net.au>

On Fri, Dec 23, 2016 at 12:26:54PM +1100, Sean Crosby wrote:

...

that's one of the things that symlinks are for.

e.g. I have python2.6, 2.7, 3.1, 3.2, 3.4, and 3.5 all installed in /usr/bin, with symlinks python & python2 pointing to 2.7, and python3 pointing to 3.5

All well and good if you're root....

and if you're not root, you can do the same things in ~/bin or edit the #! line of your script to point to your preferred interpreter. if it's not your script and you can't edit it, then either accept that it's going to be run with a system interpreter or write a wrapper script in ~/bin to call it with your preferred interpreter.

Yes but with the software our students use, they repackage python into a self contained directory, under the version of the software

they should edit the #! line then. it's not hard, and it avoids making an unmaintainable mess.

Hence why /usr/bin/env python is great.

it's not great. it's a mistake arising from inadequate understanding or knowledge of existing tools and practices. craig -- craig sanders <cas@taz.net.au>

On 23/12/16 00:57, Andrew McGlashan via luv-main wrote:

Maybe you would be better off running this in while loop in a terminal that you can minimize.

#!/usr/bin/env bash

( cd /home/dz/shots while : do /usr/bin/scrot 'scap-%Y-%m-%d-%H:%M.jpg' \ -q 70 \ -e 'chown dz.dz $f' sleep 120 done ) &> /tmp/scap.debug Thanks. I'm starting the script from "Startup applications" from my administration menu. This seem to be doing what I want:

#!/bin/bash cd /home/dz/shots while : do /usr/bin/scrot 'scap-%Y-%m-%d-%H:%M.jpg' \ -q 70 \ -e 'chown dz.dz $f' sleep 60 done