I tried to change the ipython qtconsole font size with reference to this answer in stackoverflow; however, the font size refused to change no matter how I change the ~/.ipython/profile_default/ipython_config.py.
➜ ~ ipython profile locate
/home/nick/.ipython/profile_default
➜ ~ head .ipython/profile_default/ipython_config.py
# Configuration file for ipython.
c = get_config()
c.IPythonWidget.font_size = 16
c.IPythonWidget.font_family = 'Source Code Pro'
➜ ~ uname -a
Linux nick-thinkpad 4.2.5-1-ARCH #1 SMP PREEMPT Tue Oct 27 08:13:28 CET 2015 x86
_64 GNU/Linux
➜ ~ ipython --version
4.0.0
To my suprise, ipython qtconsole --ConsoleWidget.font_size=16 works. What's wrong with my configuration?
From version 4.0 on ipython qtconsole is deprecated (because of the big split). Instead, use jupyter qtconsole. You can set the fontsize by adding c.ConsoleWidget.font_size = 12 to ~/.jupyter/jupyter_qtconsole_config.py (this also sets the font size for ipython qtconsole).
Be aware of a bug in jupyter that does not allow you to automatically create a default config file. For now, you just have to create that file manually.
Related
Cisco ios-xr router using CLI:
RP/0/RP0#show version
Thu Nov 25 07:53:59.103 UTC
Cisco IOS XR Software, Version 6.5.32.11I
Copyright (c) 2013-2020 by Cisco Systems, Inc.
RP/0/RP0#run
Thu Nov 25 07:54:05.231 UTC
[xr-vm_node0_RP0_CPU0:~]$df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 3966080 1332040 2412860 36% /
76892 11848320 43% /mnt/ecu/vdd
[xr-vm_node0_RP0_CPU0:~]$
Using python:
I am able to run show commands using Connecthandler .send.command:
from netmiko import ConnectHandler
import subprocess
Network_Device = {"host": "10.111.22.333", "username": "USER123", "password": "Pass123", "device_type": "cisco_xr",}
Connect = ConnectHandler(**Network_Device)
Connect.enable()
version1 = "show version"
print(Connect.send_command(version1))
But not able to run 'df' or 'ls' commands, as not able to reach bash prompt i reach by running 'run' command on router.
I tried:
disk1files = subprocess.run("df", stdout=subprocess.PIPE)
print(disk1files.stdout.decode())
But seems its wrong. Please suggest the right library or code I can use here.
This is my first question here, so bear some silly questions or mistakes done in code
if on DF you are referring to "Don't fragment" then it is posible to send it like
Connect.send_command("ping 192.168.10.10 df-bit size 1600")
where 1600 represents MTU, and for ls commands is link command,
Connect.send_command("ls-active")
Connect.send_command("ls-active-enabled")
but if you are referring to df and ls in linux (disk free and list files..) then you can use os module for sending commands:
import os
os.system("ls -l")
or use call from subprocess module:
from subprocess import call
call(["ls", "-l"])
If you need to acccess cisco bash:
switch# configure terminal
switch(config)# feature bash-shell
switch# run?
run Execute/run program
run-script Run shell scripts
switch# run bash?
bash Linux-bash
switch# run bash
bash-4.2$ whoami
admin
bash-4.2$ pwd
/bootflash/home/admin
bash-4.2$
In order to have code-completion and functioning linting, I'd like VSCode to include a specific path.
https://code.visualstudio.com/docs/python/environments#_environment-variable-definitions-file
I created a test environment
$ pwd
==> /Users/stephan/saitc/test_ws
$ ls -a
==> . .env tst_pckg
==> .. __init__.py
==> .DS_Store testing.code-workspace
$ cat .env
==> PYTHONPATH="/Users/stephan/saitc"
$ ls tst_pckg/
==> CONST.py __init__.py testing.py
$ cat tst_pckg/CONST.py
==> # -*- coding: utf-8 -*-
==>
==> TEST_CONSTANT = "Test constant's value"
$ cat tst_pckg/testing.py
==> # -*- coding: utf-8 -*-
==>
==> from test_ws.tst_pckg.CONST import TEST_CONSTANT
The setting "python.envFile" is set to "${workspaceFolder}/.env"
With this setup I would expect that VSCode is aware of the package "test_ws" but typing the line:
from test_ws.tst_pckg.CONST import TEST_CONSTANT
in the file "testing.py" gives my no reasonable code completion and "test_ws.tst_pckg.CONST" can not be resolved ("unresolved import"-error in the VSCode ui).
I'm using Anaconda on macos and the Visual Studio Code 1.30.1 which comes with it. Can it be that I have to start visual studio code from the directory "/Users/stephan/saitc/test_ws"? (if so how?)
With every start of Visual Studio Code I'm asked if I want to start the pylint extension. How can I turn this on permanently? (Python›Linting: Pylint Enabled, Python›Linting: Enabled)
Thank you,
Stephan
You can use the configuration "python.autoComplete.extraPaths": ["./your-source/folder"].
As far as I understand is the env file only used when you start a terminal and so on but not for the extensions.
I know there are multiple version of this question on SO, I've tried the solutions posted on those threads and they don't seem to help :(
I have VS Code installed in an Ubuntu VM. I can't seem to get the python linter to work. i.e. I get a message saying
Linter pylint is not installed
I am pretty sure pylint is installed on the VM because when I run which pylint I have a valied output.
Here are the outputs for which python and which pylint respectively
/usr/bin/python
/home/rakshak/.local/bin/pylint
And I have the following in my User settings and workspace settings in VS Code
// Place your settings in this file to overwrite the default settings
{
"python.linting.pylintEnabled": true,
"python.linting.pylintPath": "/home/rakshak/.local/bin/pylint",
"python.pythonPath": "/usr/bin/python"
}
So, turns out this was just a permissions issue!
When I got the pylint not installed message, I was presented with a button to "Install pylint" this runs
sudo pip install pylint
This changed the owner of my .local/lib/ to root and made it inaccessible to vscode.
Output of ls -ld ~/.local/lib/ was
drwx------ 3 root root 4096 Sep 24 10:49 /home/userName/.local/lib/
Runing chown with my group and user fixed this issue.
sudo chown -R group:user ~/.local
now the output of ls -ld ~/.local/lib/ reads
drwx------ 3 userGroup userName 4096 Sep 24 10:49
/home/rakshak/.local/lib/
Have you checked with which python version you have installed pylint?
If you have used python 3.6 then the setting has to be like this:
"python.pythonPath": "/usr/bin/python3.6"
I am using Enthought's Canopy environment on a 64 bit Linux OS. Everything works fine in the Ipython console which is attached with the editor. But when I ipython in the terminal and try to use magic functions, I get the following error.
---------------------------------------------------------------------------
error Traceback (most recent call last)
<ipython-input-3-29a4050aa687> in <module>()
----> 1 get_ipython().show_usage()
/home/shahensha/Development/Canopy/appdata/canopy-1.0.3.1262.rh5-x86_64/lib/python2.7/site-packages/IPython/core/interactiveshell.pyc in show_usage(self)
2931 def show_usage(self):
2932 """Show a usage message"""
-> 2933 page.page(IPython.core.usage.interactive_usage)
2934
2935 def extract_input_lines(self, range_str, raw=False):
/home/shahensha/Development/Canopy/appdata/canopy-1.0.3.1262.rh5-x86_64/lib/python2.7/site-packages/IPython/core/page.pyc in page(strng, start, screen_lines, pager_cmd)
188 if screen_lines <= 0:
189 try:
--> 190 screen_lines += _detect_screen_size(screen_lines_def)
191 except (TypeError, UnsupportedOperation):
192 print(str_toprint, file=io.stdout)
/home/shahensha/Development/Canopy/appdata/canopy-1.0.3.1262.rh5-x86_64/lib/python2.7/site-packages/IPython/core/page.pyc in _detect_screen_size(screen_lines_def)
112 # Proceed with curses initialization
113 try:
--> 114 scr = curses.initscr()
115 except AttributeError:
116 # Curses on Solaris may not be complete, so we can't use it there
/home/shahensha/Development/Canopy/appdata/canopy-1.0.3.1262.rh5-x86_64/lib/python2.7/curses/__init__.pyc in initscr()
31 # instead of calling exit() in error cases.
32 setupterm(term=_os.environ.get("TERM", "unknown"),
---> 33 fd=_sys.__stdout__.fileno())
34 stdscr = _curses.initscr()
35 for key, value in _curses.__dict__.items():
error: setupterm: could not find terminfo database
So, I installed a bare bones iPython shell which is not the one provided by Canopy and tried the same magic functions in there and it works fine.
Have I done something wrong with the installation? Please help
Thanks a lot
shahensha
This is not a solution, but just an observation. My desktop is MacOS-X and I connect to a Centos machine to run Enthought Canopy both 64 bit. I get the same error message as OP if I ssh from iterm2, but not if I use the Terminal app.
I am not sure what the underlying reason is, but may be someone can verify if a similar situation is true for linux. Interestingly I can use either iterm2 or Terminal on the local canopy without any issues.
Update:
I just noticed that the TERM environment variable in iterm2 was set to "xterm" while the Terminal app was showing "xterm-256color". Issuing the command export TERM="xterm-256color" before running the Canopy ipython in terminal solves the issue for me in iterm2.
Problem reproduction:
$ python -c 'import curses; curses.setupterm()'
Traceback (most recent call last):
File "<string>", line 1, in <module>
_curses.error: setupterm: could not find terminfo database
This irc log gave me the idea that this error was to do with libncursesw.
My Canopy version is 1.0.3.1262.rh5-x86_64. I have installed it to ~/src/canopy.
In ~/src/canopy/appdata/canopy-1.0.3.1262.rh5-x86_64/lib we can see that my canopy install has libncursesw.so.5.7.
My machine (Debian Wheezy 64bit) has libncursesw.so.5.9 (in /lib/x86_64-linux-gnu/libncursesw.so.5.9). I made canopy use this. You can toggle the problem on / off by using LD_PRELOAD and pointing at the .so file.
Solution
Replace libncurses.so.5.7 with libncurses.so.5.9:
CANOPYDIR=$HOME/src/canopy
CANOPYLIBS=$CANOPYDIR/appdata/canopy-1.0.3.1262.rh5-x86_64/lib/
SYSTEMLIBS=/lib/x86_64-linux-gnu
cp $SYSTEMLIBS/libncurses.so.5.9 $CANOPYLIBS
ln -sf $CANOPYLIBS/libncurses.so.5.9 $CANOPYLIBS/libncurses.so.5
It appears that Canopy User Python is not your default. See this article:
https://support.enthought.com/entries/23646538-Make-Canopy-s-Python-be-your-default-Python-i-e-on-the-PATH-
Update: Not true here -- instead, see batu's workaround answer.
I am puzzled by the following sequence of commands.
sh-4.2$ pwd
/home/willard
sh-4.2$ ls -l f
-rwxr-xr-x 1 willard users 59116 Jan 23 14:54 f
sh-4.2$ file f
f: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, BuildID[sha1]=0xea0e08ff2b5a062698d45b78177acdd6bf140d1f, stripped
sh-4.2$ ./f
sh: ./f: No such file or directory
sh-4.2$ strace ./f
execve("./f", ["./f"], [/* 32 vars */]) = -1 ENOENT (No such file or directory)
write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
exit_group(1) = ?
+++ exited with 1 +++
sh-4.2$ ls -l f
-rwxr-xr-x 1 willard users 59116 Jan 23 14:54 f
sh-4.2$ uname -a
Linux xdat10 3.6.2-1-ARCH #1 SMP PREEMPT Fri Oct 12 23:58:58 CEST 2012 x86_64 GNU/Linux
How is this possible?
I found someone having the same problem (with relative explanation)
Running 32bit binary on a 64bit system
Quoting the most important sentences:
This situation often arises when you try to run a binary for the right
system (or family of systems) and superarchitecture but the wrong
subarchitecture. Here you have ELF binaries on a system that expects
ELF binaries, so the kernel loads them just fine. They are i386
binaries running on an x86_64 processor, so the instructions make
sense and get the program to the point where it can look for its
loader. But the program is a 32-bit program (as the file output
indicates), looking for the 32-bit loader /lib/ld-linux.so.2, and
you've presumably only installed the 64-bit loader
/lib64/ld-linux-x86-64.so.2 in the chroot.
You need to install the 32-bit runtime system in the chroot: the
loader, and all the libraries the programs need. On Debian amd64, the
32-bit loader is in the libc6-i386 package. You can install a bigger
set of 32-bit libraries by installing ia32-libs.
I bet there's a better way to verify this but i'd try to exec
ldd ./f
and search in the output which loader is needed to exec'it
man 2 execve:
ENOENT The file filename or a script or ELF interpreter does not
exist, or a shared library needed for file or interpreter can‐
not be found.
You could run ldd against this binary to look for libraries that could not be mapped and install them from multilib.