sound policy on global variables for "distributed" DWIM function

sound policy on global variables for "distributed" DWIM function

[Emanuel Berg]

I have put together a DWIM function to take
screenshots (or dumps), and it can be invoked in
X just as well as in the console with the wrapper
detecting which one and acting accordingly.

My question is, you see that the data item ".png"
appears in *both* specialized functions (dump-vt and
dump-x), but it is likely that if I ever were to
abandon PNG for some other format, I'd want that for
dumps both of the VTs and X.

So, do I put that data a global variable (and what is
the best way to do that?), or do I have a function
return that value and thus have two invocations but
only one data item, or do I do something else?

What is the rule of thumb?

Other comments on the code are also appreciated :)

#! /bin/zsh

# This file: http://user.it.uu.se/~embe8573/conf/.zsh/dump

dump-vt () {
    local file=$1.png
    local vt=$2
    case $# in
        (1) fbgrab $file              ;;
        (2) sudo fbgrab -c $vt $file
            sudo chown $USER $file    ;;
    esac
}

dump-emacs () { dump-vt $1 1 } # because Emacs runs in tty1

dump-x () {
    local file=$1.png
    local window_name=$2
    local window_id=`wmctrl -l | grep -i $window_name | cut -d " " -f1`
    case $# in
        (1) sleep 10; xwd -root                         ;;
        (2) wmctrl -a $window_name; xwd -id $window_id  ;;
    esac | convert - $file
}

dump () {
    if [[ $DISPLAY ]]; then
        dump-x $@
    else
        dump-vt $@
    fi
}

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: sound policy on global variables for "distributed" DWIM function

[Joshua Krusell]

Greetings from a fellow UU-er!

On 22/07/15 at 02:37, Emanuel Berg wrote:
> So, do I put that data a global variable (and what is
> the best way to do that?), or do I have a function
> return that value and thus have two invocations but
> only one data item, or do I do something else?

Define a variable in your script, export an environmental var if it's
being sourced (beware name collisions, use a prefix), or even pass it as
an argument; it's up to you.

/jsks

Re: sound policy on global variables for "distributed" DWIM function

[Emanuel Berg]

Joshua Krusell <js.shirin@gmail.com> writes:

> Define a variable in your script, export an
> environmental var if it's being sourced (beware name
> collisions, use a prefix), or even pass it as an
> argument; it's up to you.

Indeed :)

Yes, it is sourced in ~/.zshrc.

But it doesn't have to be global outside the file
where those couple of functions are defined.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: sound policy on global variables for "distributed" DWIM function

[Bart Schaefer]

On Jul 23,  1:25am, Emanuel Berg wrote:
}
} But it doesn't have to be global outside the file
} where those couple of functions are defined.

Shells do not, generally speaking, have file-scoped variables.  You
get globals, variables that are local to functions, and the exported
process environment, and that's about it.

Howver, zsh does have yet another place to stash stuff like this:
The zstyle mechanism.  The ":completion:..." format is nothing but a
convention used in compsys; styles can actually look like anything
you want.

So you could have file names for contexts, e.g.

    zstyle '*/.zsh/dump' file-extension png

and then

    dump-vt () {
	local ext
	zstyle -s $HOME/.zsh/dump file-extension ext
	local file=$1.${ext:-png}
	# ... etc ...
    }

You could also have a different file-extension based on the current
working directory, or whatever.