I try to get iPython and the notebook to work but I get this message: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 13: ordinal not in range(128). I read this: Ipython on Windows:
Recent versions of IPython (as of at least 0.12.1) use %USERPROFILE% (typically C:\Users\ under Vista and 7, or C:\Documents and Settings\ under XP) and store your configuration in a %USERPROFILE%.ipython directory. Previous versions of IPython have required manually setting a %HOME% environment variable.
If you have non-ascii characters in your username and you get a UnicodeError crash on startup, you may need to manually set %HOME% to a directory with an ASCII-only name anyway (a directory like C:\home may be good enough if you're the only user of your computer). This has not been tested on recent versions of IPython, however.
I have a user name with non-ascii characters. It looks like this is the solution but how do I fix it? I'm new to this and knows where to change the variables but I do not know what to write. I have created a folder c:\ipython that I would like to use and I run Windows 7 Home Edition. Probably easy to fix if you know how...
Fixed: Changed environment variables: IPYTHON_DIR was set to the folder c:\ipython. Tried many times with IPYTHONDIR but it did not work.
Related
I'm trying to run Neovim 0.8.1. on a Windows 11 environment.
My setup is really minimal:
I downloaded nvim-win64.zip (of version 0.8.1) from Neovim's releases page on Github.
Extracted it and moved it to a folder at C:\test\nvim-win64
Started up Neovim by executing C:\test\nvim-win64\bin\nvim.exe
Not using any custom config.
When inspecting my runtimepath, there are 2 ways of doing this:
Using :set runtimepath? (the Vimscript way). This gives me:
runtimepath=~\AppData\Local\nvim,~\AppData\Local\nvim-data\site,C:\test\nvim-win64\share\nvim\runtime,C:\test\nvim-win64\share\nvim\runtime\pack\dist\opt\matchit,C:\test\nvim-win64\lib\nvim,~\AppData\Local\nvim-data\site\after,~\AppData\Local\nvim\after
Using :lua print(vim.inspect(vim.api.nvim_list_runtime_paths())) (the Lua way). this gives me:
{ "C:\\test\\nvim-win64\\share\\nvim\\runtime", "C:\\test\\nvim-win64\\share\\nvim\\runtime\\pack\\dist\\opt\\matchit", "C:\\test\\nvim-win64\\lib\\nvim" }
As you can see, it seems like using the Lua way I'm missing the local config directories in my runtimepath (the ~\AppData\Local\* paths).
Why am I seeing this difference? This is blocking me from using XDG_CONFIG_HOME to use my own config that I typically use, because it seems like it does not get included in the nvim_list_runtime_paths list, but it does appear in :set runtimepath?.
Nvim api function filters out non-existent directories. So there's a difference.
My issue was that my employer had decided to put ( and ) characters in my %USERPROFILE% environment variable, which ended up breaking a bunch of stuff (including the list I got from nvim_list_runtime_paths).
Putting those characters in %USERPROFILE% is a bad idea for many reasons, so I moved all of my files and folders out of any (sub)directory in %USERPROFILE% and right in C:\.
I also had to define XDG_CONFIG_HOME, XDG_DATA_HOME and XDG_STATE_HOME to point to a different location than the default location (which default within %USERPROFILE%).
This made all of my troubles go away!
I set ANT_HOME=C:\Program Files\ant-1.8.0
then try to build local host by Weblogic. But, it gives me the following error:
C:\Program' is not recognized as an internal or external command.
I already tried putting quotes when defining the variable: "ANT_HOME=C:\Program Files\ant-1.8.0". but it is not working either, it shows the following error message:
Files\ant-1.8.0""=="" was unexpected at this time.
I have been stuck here for the past few weeks. Iv'e googled it many times but I still cant resolve the problem.
Edited:
dir c:\pro /x
didn't show the Progra~1 and Progra~2
set "var=content" is a good practice to avoid having unintended trailing spaces, but your error occures when using the value. There you need qoutes (that are not part of your variable content with the above syntax):
set "folder=c:\program Files"
dir %folder%
dir "%folder%"
the first dir will give you "file not found", because it tries to show you the contents of c:\program (which doesn't exist) plus the contents of files (which also doesn't exist). The second dir will show you successfully the contents of "c:\program files"
Even current versions of Windows automatically create a second file name which adheres to the old 8.3 naming scheme which has been there since DOS was invented. This name does not contain a space character which makes it a good candidate to be used in scenarios like that described by you.
Unless this has been explicitly disabled you can show the alternative filenames.
Open a dosbox and enter dir C:\pro* /x. The result will be similar to this:
I ran this on a German Windows 10 Pro but the output will be identical on other versions of Windows.
You can see that for C:\Program Files Windows created an alternative name C:\Progra~1.
I need to add a new path (sumatraPDF) on my PATH variable.
I don't know why it does not work...
I think everything is right but when I try to execute sumatrapdf.exe from CMD it cannot find the program.
This is what I did:
The path is correct, I checked it 1000 times.
The idea is use LaTeX with sublimetext and when I save a .text file sumatra has to open and show to me the result. If I want that I have to add the path of SumatraPDF... but it does not work.
I think you are editing something in the windows registry but that has no effect on the path.
Try this:
How to Add, Remove or Edit Environment variables in Windows 7
the variable of interest is the PATH
also you can type on the command line:
Set PATH=%PATH%;(your new path);
Another method that worked for me on Windows 7 that did not require administrative privileges:
Click on the Start menu, search for "environment," click "Edit environment variables for your account."
In the window that opens, select "PATH" under "User variables for username" and click the "Edit..." button. Add your new path to the end of the existing Path, separated by a semi-colon (%PATH%;C:\Python27;...;C:\NewPath). Click OK on all the windows, open a new CMD window, and test the new variable.
I founded the problem:
Just insert the folder without the executable file.
so Instead of:
C:\Program Files (x86)\SumatraPDF\SumatraPDF.exe
you have to write this:
C:\Program Files (x86)\SumatraPDF\
In answer to the OP:
The PATH environment variable specifies which folders Windows will search in, in order to find such files as executable programs or DLLs. To make your Windows installation find your program, you specify the folder that the program resides in, NOT the program file itself!
So, if you want Windows to look for executables (or other desired files) in the folder:
C:\PHP
because, for example, you want to install PHP manually, and choose that folder into which to install PHP, then you add the entry:
C:\PHP
to your PATH environment variable, NOT an entry such as "C:\PHP\php.exe".
Once you've added the folder entry to your PATH environment variable, Windows will search that folder, and will execute ANY named executable file you specify, if that file happens to reside in that folder, just the same as with all the other existing PATH entries.
Before editing your PATH variable, though, protect yourself against foul ups in advance. Copy the existing value of the PATH variable to a Notepad file, and save it as a backup. If you make a mistake editing PATH, you can simply revert to the previous version with ease if you take this step.
Once you've done that, append your desired path entries to the text (again, I suggest you do this in Notepad so you can see what you're doing - the Windows 7 text box is a pain to read if you have even slight vision impairment), then paste that text into the Windows text box, and click OK.
Your PATH environment variable is a text string, consisting of a list of folder paths, each entry separated by semicolons. An example has already been given by someone else above, such as:
C:\Program Files; C:\Winnt; C:\Winnt\System32
Your exact version may vary depending upon your system.
So, to add "C:\PHP" to the above, you change it to read as follows:
C:\Program Files; C:\Winnt; C:\Winnt\System32; C:\PHP
Then you copy & paste that text into the windows dialogue box, click OK, and you should now have a new PATH variable, ready to roll. If your changes don't take effect immediately, you can always restart the computer.
The path is a list of directories where the command prompt will look for executable files, if it can't find it in the current directory. The OP seems to be trying to add the actual executable, when it just needs to specify the path where the executable is.
Try this in cmd:
cd address_of_sumatrapdf.exe_file && sumatrapdf.exe
Where you should put the address of your .exe file instead of adress_of_sumatrapdf.exe_file.
I use some .sty-files that are not part of texlive and want to have them in a subdirectory of the folder with my main.tex. I used the following line to load the package:
\usepackage{sty/prettythesis}
This works, but compiling the main.tex with xelatex and using rubber gives me a warning:
sty/prettythesis.sty: You have requested package `sty/prettythesis',
but the package provides `prettythesis'. (page 1)
Is there a way to prevent this warning or handle this case without having to include "sty\" in all .sty-files' \ProvidesPackage command or set the TEXINPUTS environment variable (which seems not to be possible from the main.tex itself)?
I believe this thread here:
LaTeX Community • View topic - Including tex files
talks about precisely the same thing: so it seems, the only alternatives are either using TEXINPUTS environment variable; or using the import package. (note, there is a variant on the import package on ...Including tex files pg 3.)
A bit more about TEXINPUTS:
TeX Frequently Asked Questions -- “Temporary” installation of (La)TeX files
Setting TeX Environment Variable Paths
Environment Variables for Running LaTeX
TeX (and Variations) for Writing Math - math.umn.edu (see 'TeX Inputs')
Installing LaTeX packages - TeX search paths
Hope this helps;
Cheers!
EDIT: I hoped that one could set the TEXINPUTS path directly in the tex file (by using \write18 -- and note, some versions of LaTeX use --enable-write18, mine uses -shell-escape to enable \write18; see also this) - but it seems it is not possible:
"... This isn't possible. ... The environment variable of the child process is set, but this hasn't an effect to its parent process (TeX)." (Re: Setting the environmental variable TEXINPUTS within latex - comp.text.tex).
... so, now I just call pdflatex in my Linux bash like this:
TEXINPUTS=.//:$TEXINPUTS pdflatex ./myfile.tex
and then it will resolve directly \usepackage{mypackage} in the myfile.tex file - even if mypackage.sty is in a subdirectory, say ./subdir/mypackage.sty.
As you discovered, putting the package in a subdirectory (say, ./sty/prettythesis.sty with respect to your main .tex file at ./), and calling the package via
\usepackage{sty/prettythesis}
will successfully load the package, but it will produce the warning
sty/prettythesis.sty: You have requested package `sty/prettythesis',
but the package provides `prettythesis'. (page 1)
If all you want is to get rid of this warning, and you're OK with minor modifications in the .sty file, then you can simply change the package name that it reports, by changing the \ProvidesPackage command to
\ProvidesPackage{sty/prettythesis}
This can be inconvenient if you're going to be moving it around loads, but the modifications load isn't too bad either.
Even better, if what you have in there is a specific, modified version of a standard TeX package (like, say, this patch of natbib), then the change in the package name clearly indicates what package it's providing, and if you reuse the file then it will (most likely) re-raise a warning to prompt you into making sure that you know what you're doing.
You can do it in your TeX file without changing your system's environment (do not forget the trailing slash / with each directory):
\makeatletter
\def\input#path{{../one-directory/}{../another-directory/}}
\makeatother
\documentclass{myclass}
\usepackage{mypackage}
This way, though, may be not recommended for portability. As other answers mention, the "correct" way is to set the TEXINPUTS variable in your system environment before you call latex; in Windows it is (you can place it in a batch file):
set TEXINPUTS=../one-directory/;../another-directory/;%TEXINPUTS%
pdflatex myfile.tex
Simply put line below before the call to pdflatex (or latex) in your makefile or build script:
export TEXINPUTS=".:./sty:"
Then reference your package as:
\usepackage{prettythesis}
I'm running into an issue with the portion of the Rails generation script that searches the plugin path for appropriately named files to find generators. On one of my systems, I have Ruby installed in c:\dev\ruby and have my project directory at d:\local\projects
The Ruby Pathname#relative_path_from method (which is called by the Rails generator script) chokes on this configuration when it attempts to find the relative path between c:\ and d:\...
Has anyone run into this situation with relative_path_from and multiple drives on Windows? Is there a workaround for the rails generator script?
Here's a sample from IRB:
>> x = Pathname.new('c:/dev/ruby')
=> #<Pathname:c:/dev/ruby>
>> y = Pathname.new('d:/local/projects')
=> #<Pathname:d:/local/projects>
>> x.relative_path_from(y)
ArgumentError: different prefix: "c:/" and "d:/local/projects"
from c:/dev/ruby/lib/ruby/1.8/pathname.rb:709:in `relative_path_from'
from (irb)...
If there's no solution, I could always make sure my Ruby install and project directories are on the same drive, but that would prevent me from ever working off a project directory on a pendrive...
UPDATE: Turns out the issue is related specifically to some modification that the Radiant CMS makes to the Rails configuration variables. This change adds additional plugin directories to the project, some of which can cross drive boundaries. Since the Rails generator code doesn't expect that sort of drive-jumping, the generator breaks on my computer...
Would there be a way to compute a relative path across two different drives in Windows? I don't know.
You can avoid the problem by mounting your D: drive as a folder on your C: drive, assuming you're using NTFS. If that's not acceptable, you could create a junction from D:\local to C:\local which would let you access D:\local from both D: and C:. Then, running the same script from the C: drive should pose no problems.
How to create and use NTFS mounted drives in Windows XP and in Windows Server 2003
How to create and manipulate NTFS junction points
Junction Utility by SysInternals
The problem is this as documented in a ticket at http://redmine.ruby-lang.org/issues/show/1366
On Windows, the case of the drive letter can be either upper-case or lower-case (e.g., "C:" or "c:") on the same machine at the same time in different Command Prompt Windows (see below for details). Dir.pwd will return either lower-case or upper-case for the drive letter ("C:" or "c:") depending on the Command Prompt it is run from. However, __FILE__ always uses lower-case drive letter. This can cause an ArgumentError when comparing Dir.pwd and __FILE__ using Pathname#relative_path_from. This happens with version 1.9.1p0 as well. Pathname#relative_path_from should deal with the case where the case of the argument is different.
I have both my ruby install folder and my project folder on c: drive, but I still get the error. I monkey-patched the following lines in pathname.rb file as shown below marked within two asterisk. Remove the two asterisk when you patch.
def relative_path_from(base_directory)
dest_directory = self.cleanpath.to_s.**capitalize**
base_directory = base_directory.cleanpath.to_s.**capitalize**
...
It works after the patch. Hope it helps.