less failling to run

[thiblahute]

thiblahute@thiblahute ~/devel/gstreamer/gst-build master $ xonsh --version
xonsh/0.5.3
thiblahute@thiblahute ~/devel/gstreamer/gst-build master $ uname -r
4.9.6-1-ARCH

Trying to run less fails and start running it in the background as follow:

thiblahute@thiblahute ~/devel/gstreamer/gst-build master $ touch tmp
thiblahute@thiblahute ~/devel/gstreamer/gst-build master $ less tmp
^Z
thiblahute@thiblahute ~/devel/gstreamer/gst-build master $ ps
  PID TTY          TIME CMD
...
24024 pts/9    00:00:00 less
...

I did not press Z or anything it just happened without doing anything.

I do not have much configs (yet) just a few aliases and 'exports'.

[gforsyth]

Thanks for reporting @thiblahute! That's a weird one. Do you still have errors or random ^Zs if tmp is not an empty file? And can you post the output of xonfig please? Thanks!

[scopatz]

Also, I think this may have already been fixed on master, if you could try that too, please.

[gforsyth]

hey @scopatz -- it's mostly fixed on my end, although opening an empty file with less will exit immediately instead of displaying the empty file

[scopatz]

hmm weird. It works for me. Do you have less aliased to anything?

[gforsyth]

No idea why, but it works for me, too, now... I was really sure it bailed on me before but I'll defer to my lying eyes.

[gforsyth]

weird... every once out of a bunch of times it does just quit. i'll see if I can duplicate that for a nonempty file...

[gforsyth]

damn. yeah, sometimes less just doesn't do anything. that's a separate issue though, and i'll have to see if i can come up with a reproducible example

[scopatz]

software == the worst

[thiblahute]

Thanks for reporting @thiblahute! That's a weird one. Do you still have errors or random ^Zs if tmp is not an empty file? And can you post the output of xonfig please? Thanks!

Yes, it does not matter if it is an empty file or not, also I noticed git show or anything starting less will fail the same way.

^Z
thiblahute@thiblahute ~/devel/gstreamer/gst-build master $ xonfig
+------------------+-----------------+
| xonsh            | 0.5.3           |
| Python           | 3.6.0           |
| PLY              | 3.9             |
| have readline    | True            |
| prompt toolkit   | 1.0.9           |
| shell type       | prompt_toolkit  |
| pygments         | 2.2.0           |
| on posix         | True            |
| on linux         | True            |
| distro           | arch            |
| on darwin        | False           |
| on windows       | False           |
| on cygwin        | False           |
| is superuser     | False           |
| default encoding | utf-8           |
| xonsh encoding   | utf-8           |
| encoding errors  | surrogateescape |
+------------------+-----------------+

OK I now have a pretty good hint, basically it only happens when I am inside a gst-uninstalled environement, which is setup using this script so I nailed down and manage to reproduce with:
python3 -c "import subprocess; subprocess.call(['/usr/bin/xonsh'])"

Example:

thiblahute@thiblahute ~/devel/gstreamer/gst-build master $ python3 -c "import subprocess; subprocess.call(['/usr/bin/xonsh'])"
thiblahute@thiblahute ~/devel/gstreamer/gst-build master $ git log
^Z
thiblahute@thiblahute ~/devel/gstreamer/gst-build master $ 

while running from outside that env works just fine.

I will try with master.

[thiblahute]

Same thing on master in a venv.

[scopatz]

Nice, OK, I can reproduce this via the subprocess method.

[scopatz]

@thiblahute, I am a bit confused about your workflow. Are you running xonsh from within gst-uninstalled or are you running gst-uninstalled within xonsh (which looks like it will launch your login shell, which may be xonsh)?

[scopatz]

It seems like you might have xonsh at the top-level. If I go bash -> python -c xonsh -> git log everything works

[thiblahute]

Basically I have zsh -> xonsh -> gst-uninstalled -> xonsh so I am inside the gst-uninstalled environment inside xonsh, and yes if I go zsh -> SHELL=xonsh ./gst-uninstalled -> xonsh it works.

Also xonsh -> gst-uninstalled -> xonsh (using xonsh as default terminal) fails.

[scopatz]

@thiblahute what does you xonshrc look like? Also, as a potential fix, could you try adding the following to your xonshrc:

__xonsh_commands_cache__.threadable_predictors['gst-uninstalled'] = lambda args: False

[thiblahute]

@thiblahute what does you xonshrc look like? Also, as a potential fix, could you try adding the following to your xonshrc:

Well it is a bit funky and hacky, but here we go:

import os
from subprocess import run as r
from subprocess import check_output as c

$FLATPAK_ENVPATH = "/home/thiblahute/devel/pitivi/flatpak/"

def obuild(full=False):
    d = os.path.expanduser($MGST + '/gst-build/odroidbuild')
    r('ninja', cwd=d)
    tmpf = '/tmp/obuildrsync'
    with open(tmpf, 'w') as f:
        cmd = ["find", "."]
        if not full:
            cmd += ["-cmin", "-5"]
        cmd += ["-name", "*.so*"]
        f.write(c(cmd, cwd=d).decode())
        r(['rsync', '-a', '--progress', '--files-from', tmpf, './', 'odroid:/home/thiblahute/devel/gstreamer/gst-build/build/'], cwd=d)

def parse_file(path):
    with open(os.path.expanduser(path)) as a:
        for l in a.readlines():
            if l.endswith('\\'):
                print("Can not evaluate %s" % l)
                continue
            if l.startswith("alias"):
                vs=l.replace('alias', '').strip().split('=')
                aliases[vs[0]] = vs[1].replace('"', '').replace("'", '')
            elif l.startswith("export"):
                vs=l.replace('export', '').strip().split('=')
                if vs[0] == 'PATH':
                    vs[1] = vs[1].replace('$PATH', os.pathsep.join(__xonsh_env__['PATH']))
                __xonsh_env__[vs[0]] = vs[1].replace('"', '').replace("'", '')

parse_file('~/.envvars')
parse_file('~/.envvars.local')
parse_file('~/.aliases')
parse_file('~/.aliases.local')
aliases["pitivi-git"] = ["source", "~/bin/pitivi-xonsh-env"]
__xonsh_env__['BASH_COMPLETIONS'] = ['/usr/share/bash-completion/completions/git',
                                     '/usr/share/bash-completion/completions/systemctl']
$SHELL='/usr/bin/xonsh'
xontrib powerline
xontrib prompt_vi_mode
__xonsh_commands_cache__.threadable_predictors['gst-uninstalled'] = lambda args: False

Last addition __xonsh_commands_cache__.threadable_predictors['gst-uninstalled'] = lambda args: False does not solve it.

Moreover, emptying my xonshrc does not solve the issue either.

[scopatz]

Wait, so what actually runs the gst-uninstalled?

[thiblahute]

Wait, so what actually runs the gst-uninstalled?

No I run it after starting xonsh.

[scopatz]

Can you try starting xonsh with --no-rc and then running it? And also try adding the commands cache line before running gst-uninstalled dynamically

[scopatz]

And what command are you using to run gst-uninstalled? Just to be exact, are there any aliases etc?

[thiblahute]

No, no alias, just running `./gst-uninstall` lead to that issue.

…

On Sat, Feb 11, 2017 at 7:44 PM, Anthony Scopatz ***@***.***> wrote: And what command are you using to run gst-uninstalled? Just to be exact, are there any aliases etc? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2164 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFGYV9OKU2ZslrxuDjFZLDWz3FE9aluks5rbjm2gaJpZM4L53o4> .

[scopatz]

Ok then that commands cache trick should have worked. Can you run the following with the commands cache False set and report back please?

$ x = ![./gst-uninstall]
$ x.specs

[thiblahute]

OK, sorry about that the script is `gst-uninstalled.py` and replacing your line with `__xonsh_commands_cache__.threadable_predictors['gst-uninstalled.py'] = lambda args: False` does fix the issue. Any idea how to properly fix it or should I just keep using that line ? :) Usually I used to use `ninja -C build/ uninstalled` to get into the GStreamer uninstalled env, it does not work with your cache trick though (I can change my way of doing it anyway).

…

On Sat, Feb 11, 2017 at 7:56 PM, Anthony Scopatz ***@***.***> wrote: Ok then that commands cache trick should have worked. Can you run the following with the commands cache False set and report back please? $ x = ![./gst-uninstall] $ x.specs — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2164 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFGYdjwU1heHDL7jGhXHzR7MWnwMlZyks5rbjyKgaJpZM4L53o4> .

[scopatz]

Any idea how to properly fix it or should I just keep using that line ? :)

@thiblahute That is the correct fix for now. Much more than other codes, I think gst-uninstalled.py is misbehaving here, though we'll support it to the best of our ability. Your more general case of

$ python3 -c "import subprocess; subprocess.call(['/usr/bin/xonsh'])"

is again something where users will have to manually turnoff the threadability (temporarily?) for calling Python in a subprocess. Basically, right now xonsh can't capture output, stream output, and remain interactive on the main thread. (This is due to some limitations in subprocess.) So we have a special mechanism for handling when we want to run on the main thread and we don't care about streaming output. gst-streamer.py, by running xonsh indirectly, is trying to have it all.

In generaly, if you are having problems like this, such as with ninja, you can add a similar lambda.

__xonsh_commands_cache__.threadable_predictors['ninja'] = lambda args: False

Or if you wanted to get fancier, you could do:

__xonsh_commands_cache__.threadable_predictors['ninja'] = lambda args: 'uninstall' not in args

#2119 is another issue to add an easier way to register these kinds of functions.

[scopatz]

Also, please feel free to close this whenever you think it is ready!

[thiblahute]

Got it, not ideal but good enough for now!

Thanks a lot for you help here!

[thiblahute]

OK, one more question, what if I have an alias to launch the GSTreamer uninstalled env (ie bgst = 'ninja -C /path/to/gst-buil/build' and I use bgst uninstalled to launch it, which is what I actually used to do :))

[scopatz]

Yeah, agreed it is not ideal. @astronouth7303 has been leading the way to try to fix this.

what if I have an alias to launch the GSTreamer uninstalled env (ie bgst = 'ninja -C /path/to/gst-buil/build'

If it is a simple alias, you don't need to do anything since it will resolve the basename of the underlying binary. If you have a callable (function) alias, you may need to decorate it as unthreadable and/or uncapturable. See the docs here: http://xon.sh/tutorial.html#unthreadable-aliases

[AstraLuma]

(That effort is #2159 for the record.)