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.
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 have verified that I can run both normal office and python macros from within office but I still haven't figured out how to run one (even the hello world one) from the command line.
I have googled and looked at other answers here but I'm still not entirely clear how to run an open office macro from the command line:
https://forum.openoffice.org/en/forum/viewtopic.php?f=20&t=8232
suggests to use:
office writer.odt "macro://Standard.Module1.Macro1()"
I have also seen:
office "macro://Standard.Module1.Macro1()" writer.odt
Either way around this just opens the document and and neither runs a macro nor reports an error.
Whereas How to call an existing LibreOffice python macro from a python script
suggests to run office listening on a port and communicate via that.
If I can get that far I still need to find API documentation that will explain how to insert an anchor (as per my other question
asciidoc: is there a way to create an anchor that will be visible in libreoffice writer?)
I'm using RHEL7 for context.
update
oowriter "foo.odt" macro:///Standard.Module1.addXref
works with a office basic macro.
I still haven't figured out the python one.
One issue is I can't find any debug information to look at. Are there any log files anywhere?
Another issue is which version of python to use.
The RHEL package installs site packages for python 2.7.
>rpm -q --whatprovides /usr/bin/writer
libreoffice-writer-4.3.7.2-5.el7_2.1.x86_64
>rpm -ql libreoffice-pyuno-4.3.7.2-5.el7_2.1
...
/usr/lib64/python2.7/site-packages/uno.py
Libreoffice5.1 includes 3.5 with the distro:
>/opt/libreoffice5.1/program/python --version
Python 3.5.0
So to start with I am looking for a hello world python example that pairs a known version of python with a known version of office. Preferably either of the two above (writer 4.3.7 & python 2.7? or writer 5.1 & python 3.5).
update2
Using python3.5 as installed with office5.1 I have a working hello world using the following:
import uno
# get the uno component context from the PyUNO runtime
localContext = uno.getComponentContext()
# create the UnoUrlResolver
resolver = localContext.ServiceManager.createInstanceWithContext(
"com.sun.star.bridge.UnoUrlResolver", localContext )
# connect to the running office
ctx = resolver.resolve( "uno:socket,host=localhost,port=2002;urp;StarOffice.ComponentContext" )
smgr = ctx.ServiceManager
# get the central desktop object
desktop = smgr.createInstanceWithContext( "com.sun.star.frame.Desktop",ctx)
# access the current writer document
model = desktop.getCurrentComponent()
# access the document's text property
text = model.Text
# create a cursor
cursor = text.createTextCursor()
# insert the text into the document
text.insertString( cursor, "Hello World", 0 )
This works with either version of open office via:
/usr/bin/oowriter --accept="socket,host=localhost,port=2002;urp;StarOffice.ServiceManager"
So the final part is to add the cross reference.
It looks like the command needs an extra slash. This worked for me on Ubuntu:
lowriter "Untitled 1.odt" macro:///Standard.Module1.SayHello
That calls this method in the module named Module1 under My Macros & Dialogs / Standard:
Sub SayHello
MsgBox("Hello, World!")
End Sub
The above approach only works for Basic macros. For Python macros, the standard command line approach is to connect to a listening instance of Office. Warning: This will be much (perhaps 10x) slower than running from within Office.
The link you suggested shows how to call a Python macro from a different Python script, which is more complex than what we need here. Instead, put the connecting code (starting with localContext = uno.getComponentContext()) and macro code in the same script. For an example of what should go in the script, see "First play with the Python shell to get familiar" at http://christopher5106.github.io/office/2015/12/06/openoffice-libreoffice-automate-your-office-tasks-with-python-macros.html.
As far as creating anchors, there are a number of different objects in LibreOffice that can function as anchors:
Headings
Bookmarks - example code to create them
Tables and Frames
Sections
Images and OLE Objects
This list was copied from How do I check for broken internal links in Star Basic?. In your other question you also asked about checking for broken links, so hopefully that question is helpful.
One way to create a hyperlink is to edit the HyperLinkURL property of some text. For example, say there is a bookmark called MyBookmark. Then the following code changes the currently selected text into a hyperlink:
viewcursor = currentController.getViewCursor()
viewcursor.HyperLinkURL = "#MyBookmark"
EDIT:
Regarding which version of python to use, currently LibreOffice uses python 3 and OpenOffice uses python 2.
For debugging information, you can set a checkpoint in the Basic IDE. For python, I use the logging module. OpenOffice also has various log files but I normally do not find them helpful.
Regarding problems with python, did you try the link I posted? If so, how far did you get?
I do not think you will find many RHEL examples. Try to get it working on a desktop distro like Ubuntu first, and then adapt that approach to RHEL.
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 am converting a VB6 application to VB.NET. In the code I am converting, it seems that the developer found the applications path two separate ways. However, it appears that he expects the two methods to produce different results.
Simple question:
What is the difference between calling these two lines of code:
strAppDataPath = CreateObject("Shell.Application").
NameSpace(ssfLOCALAPPDATA).Self.Path
and
strAppDataPath = App.Path
Explanation:
This is the code in question:
strAppDataPath = CreateObject("Shell.Application").
NameSpace(ssfLOCALAPPDATA).Self.Path
strAppDataPath = strAppDataPath & "\DataFolder\"
If (Not objFileSystem.FileExists(strAppDataPath & strAppDataFile)) Then
If (objFileSystem.FileExists(App.Path & strAppDataFile)) Then
...
End If
End If
The application's path is appended with \DataFolder\, and stored in the String strAppDatapath.
We check if the file strAppDataFile does not exist in strAppDatapath. Followed by checking if the file does exist in App.Path.
The concept behind what is going on makes sense to me: If the file doesn't exist in the subfolder, and if the file exists in App.Path, then do .... What I do not understand is why they didn't use one of the method for finding the application's path exclusively.
They don't point to the same path.
App.Path: Path where the currently executing EXE/DLL resides.
CreateObject("Shell.Application").NameSpace(ssfLOCALAPPDATA).Self.Path: Will point to the local (non-roaming) app data user folder. Same as the value in (user) environment variable LOCALAPPDATA.
Since Windows XP, the roaming & local app data paths are preferred places to store user settings and files (instead of the probably rights-restricted app folder).
So what the code does, is:
Look for strAppDataFile in %LOCALAPPDATA%\DataFolder\ (e.g. where "%LOCALAPPDATA%" could point to "C:\Users\UserName\AppData\Local\" on Windows Vista/7)
If not found, look for the same file in the application folder.
Please note that preferably applications should create an application specific sub-directory in local/roaming app data, e.g. use something like:
strAppDataPath = strAppDataPath & "\" & App.ProductName & "\DataFolder\"
' NOTE: Make sure to set the "Product Name" entry in the version information
' of the project settings
that could resolve to something like
"C:\Users\UserName\AppData\Local\My Application\DataFolder\"
My guess is that when the program is installed per-machine, a per-user location under LocalAppData is used. However during development or when installed per-user or as a portable application the application folder is used.
Some programmers use something like the code in question, while others make the decision by comparing App.Path against the ssfPROGRAMFILES path to determine the environment. The latter is probably preferable for a number of reasons but in the degenerate case where only one instance of the program exists on a machine they're equivalent.
Let me explain my situation with some dummy file names.
I am working in directory 'A' which has a sub directory 'a'. I am running a function 'func1' which is present in both folders. 'func1' needs 'file1' & 'file2' during its execution. 'file1' & 'file2' are present in both folders with some parameters changed inside them. It is not possible for me to change file names at all.
Now, the problem is that when I am running 'func1' in 'A', everything is working fine. But, when I run 'func1' in 'a' using 'addpath/rmpath', rather than using 'file1' & 'file2' from 'a', it is using 'file1' & 'file2' from 'A' which is producing wrong results.
Please tell me how can I change path so that when I run 'func1' in sub directory 'a', it always use 'file1' & 'file2' from 'a' rather than directory 'A'.
I hope I am clear in my explanation :S
If I have understood correctly, you are hoping that if you use addpath to add the subdirectory to the search path, Matlab will give the search path precedence over the current directory. Unfortunately, it is precisely the other way around, as per the Matlab documentation: "Functions in the current folder take precedence over functions with the same file name that reside anywhere on the search path." - and this also applies to the load function when reading data files. (incidentally, I suspect that for this reason you are also not running the version of func1 that you think you are running - try typing which func1 to find out).
Anyway, the solution here is to make sure that Matlab picks the right version of file1 and file2, which you could do in several ways:
Change your working directory to a, since the working directory has precedence: cd a
Put the two versions into separate subfolders, e.g. a and b, and use addpath to add them separatley
Change the different versions of func1 to have explicit references to the files, i.e. load('./a/file1')
With addpath and rmpath you modify the search path in Matlab. Your search path basically is a list of folders where Matlab looks for functions. Not for files you want to open.
If you have your files in folder A and this is your current working directory, Matlab will look for the files in A. If you change to a and change your working directory accordingly, Matlab will open the files in a - this has nothing to do with your search path. If you want to open files from a specific directory, use the entire path in the open command:
fileID = fopen('/path/to/A/file1');
In your case, the case may be that the fopen is applied in the way explained above. If you want Matlab to always open files from the current working directory, change it to:
fileID = fopen('file1');