I'm trying to use flymake to run pyflakes, as suggested here
This works fine for local files, and almost works with remote files with a bit of tweaking, but I'm left with a problem where flymake/pyflakes 'modifies' the buffer when it runs (although nothing actually seems to change), which renders it a bit useless in practice (e.g. saving a file runs flymake which immediately modifies the buffer again).
Here's what I did to almost get it working:
Installed pyflakes on the remote box.
Customized my tramp-remote-process-environment variable so that pyflakes could be found in its PATH
Used a variant of the code from the wiki link above. Obviously I excluded the check that disables it for remote buffers. Also, the (when (load "flymake" t) ...) construct didn't seem to work as I expected, but I'm not too worried about that.
Re-defined (for test purposes -- advice should be fine if this can be made to work) the flymake-start-syntax-check-process function so that it uses start-file-process (which works with tramp) instead of start-process (which does not).
The change in #4 does not appear to cause any issues when processing a local file, but although this now enables flymake to run the remote pyflakes for the remote files (errors are highlighted as expected), in this instance the buffer is 'modified' whenever flymake runs.
I'm guessing that start-file-process, for remote processes, results in some additional return value/data that does not occur for local processes.
Does anyone have any insight/advice?
Emacs 23.1 and 23.2 on Ubuntu
Python 2.4.6
Pyflakes 0.4.0 (via easy_install)
You need to tell flymake to create it's copy of the buffer somewhere locally, I prefer using the $TMP directory since this also allows me to use tramp on files in directories I don't have write permissions to.
You may want to checkout my fork of flymake-python since it does all this.
I have this fixed in my fork of Flymake (https://github.com/illusori/emacs-flymake).
It will either run the syntax check on the remote machine via Tramp, without the buffer-modification issue you're seeing; or you can set flymake-run-in-place to nil and it will run the syntax check on the local machine, just like flymake on a regular non-Tramp buffer.
Since it's fixed at the Flymake level, this fix works for all languages and syntax checks rather than just pyflakes.
If you're interested in details of why it's happening, basically when the Tramp handler for start-file-process kicks in, it dumps the login message for the connection onto the end of the current buffer before any output filter can be attached to the process.
Usually this manifests as people seeing the contents of /etc/issue appear at the end of their file along with "You have mail." and so on.
In your case it may be that the login message is empty or just a new-line, so you're not seeing any text being added, even though it's setting the buffer as being modified.
Related
I'm trying to run a Ruby project from a Python interface, but in its most current form it only works when run from a terminal, not from a Subprocess in Python. The Ruby project consists of an executable file (let's call it exeFile) which runs a command-line interface tool (let's call it cli.rb), which requires and calls various structures from various other Ruby files in the project. The CLI file takes command-line arguments via Thor. This works in a terminal, but fails in a subprocess call when the cli.rb file has been modified.
I've made sure I'm passing all the right arguments to subprocess.Popen. For example:
popen = subprocess.Popen(['/home/daveshere/.rbenv/shims/ruby', '/media/daveshere/Data/exeFile', '--b', '1.1.1', '-p'], stdout=subprocess.PIPE, stderr=subprocess.STDOUT, stdin=subprocess.PIPE, universal_newlines=True, shell=False)
The p argument hasn't changed in the cli.rb file, and works in both the terminal and the Subprocess. But days ago, I changed the type of b from numeric to string, which allows the program to run properly. Again, this works in the terminal, but not when running from the Subprocess. Instead, printing the Subprocess output shows me the error:
Expected numeric value for '--b'; got "1.1.1"
This is despite the cli.rb file requiring a string type for b now, and the fact that the same call works in the terminal. It seems as if there is some locally-cached outdated version of the cli.rb file being called by ruby in the Subprocess, but not the terminal. I even tried adding this to the cli.rb file to see if it registers:
puts "TESTING MODIFICATION"
That string prints when running from the terminal, but not from the Subprocess (although other, older output does).
I also made sure ruby -v returns the same version in both cases, and it does. I'm really not sure what's causing the disconnect here. I'm also running the Python Subprocess via Pycharm on Ubuntu, if that has any relevance. Any ideas?
Fixed it thanks to engineersmnky's help. For whatever reason, the Subprocess, regardless of whether shell=True or shell=False was used, whether bash was or wasn't used, whether env=os.environ was used, etc., could not read the ruby environment, including the local changes to the gem. It could only read the git-published changes. I'm a ruby/gem newbie, so the reason wasn't obvious to me.
I didn't have ownership of the repo for the gem I was editing, so I created a private fork of the repo, moved my local changes to that repo, edited the *.gemspec file to reflect the changes, and built and installed a new gem locally with the same name. Now everything works. All I have to do now is remember to add my local changes to the private git and reinstall as needed when new changes are made. Technically, maybe I could have just added the local changes to the public repo without committing anything, but I'd prefer playing it safe with the private repo.
Since the windows 10 creator update, you can enable developer mode to circumvent administrator privileges when creating a symlink. Now, I was able to create a symlink using mklink like this:
os.system('mklink %s %s' %(dst, src))
Hopefully it's obvious that dst is the destination symlink path, and src is the source file for the symlink. While it seems to work ok, it doesn't error if it fails which makes it a little more difficult to ensure each symlink is successful. I can check if the path exists after each symlink, but that's less efficient than a try/except clause. There's also what looks like a command shell window(?) that pops up and closes quickly every time - and that's really annoying when you're symlinking a lot of files...
So, I've been trying other options I've found on stack overflow like this one: How to create symlinks in windows using Python? Unfortunately, the CreateSymbolicLinkW command doesn't seem to work for me... I also found this: OS.symlink support in windows where it appears you need to adjust the group policy editor; however, it apparently still requires users in the administrator group to run the process as an administrator even if you explicitly set that user with symlink privileges.
With the windows 10 creator update, there's mention of a new dwflag in the CreateSymbolicLink api (SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE) you can see the reference for that here: symlinks windows 10
Using the ctypes stuff is a bit over my head, so I'm wondering if anyone knows: Can I actually use that new dwflag? How do I use it? Will it work without running the process as administrator?
I use Autodesk Maya, so I'm stuck with python 2.7 options... I have not tried launching Maya as an administrator so I don't know if that will work, but it seems like a rather annoying hoop to jump through even if it does... I appreciate any assistance you can give
it doesn't error if it fails
os.system will return the exit status of the call. It does not raise an exception.
If you look at the docs for os.system, they recommend using the subprocess module. In fact, subprocess.check_call does what you describe (raise an exception on a non-zero exit status). Perhaps that would work better.
On the other hand, the command mklink will return a zero exit status even if the source does not exist (it will create a link to non-existent file and return 0). You might want to validate the actual link as you mentioned, depending on what errors you are trying to find.
As far as hiding the console window, see this.
os.symlink works out of the box since python 3.8 on windows, as long as Developer Mode is turned on.
Not sure whether this will help with Maya; they seem to have committed to Python 3 though.
EDIT: I got it working, I went into the pycassa directory and typed python pycassaShell but the 2nd part of my question (at the bottom there) is still valid: how do I run a script in pycassaShell?
I recently installed Cassandra and pycassa and followed the instruction from here.
They work fine, except I cant get pycassaShell to load. When I type pycassaShell at the command prompt, I get
'pycassaShell' is not recognized as an internal or external command,
operable program or batch file.
Do I need to set up a path for it?
Also, does anyone know if you can run ddl scripts using pycassaShell? It is for this reason that I want to try it out. At the moment, I'm doing all my ddl in the cassandra CLI, I'd like to be able to put it in a script to automate it.
You probably don't want to be running scripts with pycassaShell. It's designed more as an interactive environment to quickly try things out. For serious scripts, I recommend just writing a normal python script that imports pycassa and sets up the connection pool and column families itself; it should only be an extra 5 or so lines.
However, there is an (undocumented, I just noticed) optional -f or --file flag that you can use. It will essentially run execfile() on that script after startup completes, so you can use the SYSTEM_MANAGER and CF variables that are already set up in your script. This is intended primarily to be used as a prep script for your environment, similar to how you might use a .bashrc file (I don't know of a Windows equivalent).
Regarding DDL statements, I suggest you look at the SystemManager class.
I wrote a small app and I am using pynotify to show some messages to the user.
It all works fine here in arch, but when I tested it in Ubuntu, the behaviour was very weird.
Because of the way Ubuntu shows notifications (as what seems to be a rip of of growl), I can't click on them, or interact with them in any way, for that matter.
The biggest problem, however, is that it only shows one notification at a time, and has to wait (a long time, by default) untill one of them goes away to show the next one.
Given the nature of the little app I'm writing (a simple monitor that runs a command every time a file is changed), the results must appear to the user in real time.
I have tried to set a small timeout with message.set_timeout(), but Ubuntu just seems to ignore it.
--
So, here is my question: Am I the only one to notice that? Am I doing something wrong?
If not, is there any way to change that behaviour in Ubuntu? Any workaround?
Thanks in advance for your time
Yes, Ubuntu 9.10 replaced upstream's notification-daemon with their own notify-osd, and generally made a mess of things.
You can ensure notification-daemon is installed (via whatever your favorite package manager front-end is) and use it in favor of notify-osd:
$ sudo mv /usr/share/dbus-1/services/org.freedesktop.Notifications.service /usr/share/dbus-1/services/org.freedesktop.Notifications.service.disabled
$ sudo mv /usr/share/dbus-1/services/org.freedesktop.Notifications.service.notify-osd /usr/share/dbus-1/services/org.freedesktop.Notifications.service
Unfortunately this will get overwritten whenever the package is updated... it's already using a dpkg-diversion so it's hard to re-divert it permanently.
I use IPython very frequently and happily. Somehow, cutting text from the shell using the keyboard shortcut, Ctrl + X, is broken. Actually, I have a few different installations of IPython. In some of the installations, the shortcut works; in the others, it doesn't work.
What might be the reason for this? Where should I look into?
You say you have multiple instances installed -- are these all on different machines? What operating system(s) are they running? If you access them remotely, what operating system are you running?
Do you get to them using ssh? Do you run something like screen, either locally or remotely, or both? There are lots of things that can interfere with your terminal settings, especially when you're working remotely.
I'm almost certain that iPython doesn't have anything to do with it -- though you might want to check the version numbers, to see if working and non-working environments are running different versions.
More likely, it is something in the terminal emulation layer, but you'll likely have to do some detective work of your own to find out what piece is causing it.
Take it one step at a time -- try to cut from a local shell, to make sure that works. Then connect to a remote machine, and cut from that shell. Start screen, if that's your normal way of doing things, and test from that shell. Then start ipython. If it stops there, then see if you can find another application on the same machine that's linked against gnu readline, and try that. You may find that none of the console apps cut proplerly on that machine, or you may find that they work, but not under screen. Or you may find that something in the terminal settings stops everything from working as soon as you ssh in.
You may also have some luck. if you can find out what terminal the remote machine thinks you are using ( echo $TERM ) by copying the termcap file from a working machine to one that doesn't. That's a bit more involved for these forums, though -- I'd repost at that point on serverfault.com or superuser.com
I hope that at least gives you a starting place -- terminals are finicky, and difficult to get right. Most people seem to not bother, as long as everything mostly works.