Recently my vim will change current directory no matter what I do. I'm using spf13 distribution and when I am in a rails app root directory and did vi, my pwd will be correctly in app root directory. But once I open some file, any file, it will change the pwd to abosolute/path/to/myrailsapp/app/assets/stylesheets,
When I don't have let g:spf13_no_autochdir = 1 in my .vimrc, vim will change the pwd to current file directory; When I do, it will change to the stylesheet directory whenever I open a file.
I'm also using rails.vim installed. Here is the related code inside my .vimrc
if !exists('g:spf13_no_autochdir')
autocmd BufEnter * if bufname("") !~ "^\[A-Za-z0-9\]*://" | lcd %:p:h | endif
" Always switch to the current file directory
endif
UPDATE:
What I want: the pwd always stay in absolute/path/to/myrailsapp/, no changing to the stylesheet directory automatically whenever I open a file.
Actually I just found and had a look at the plugin. I assume this is it:
https://github.com/spf13/spf13-vim/blob/3.0/.vimrc
Around line 75 you can see:
" Most prefer to automatically switch to the current file directory when
" a new buffer is opened; to prevent this behavior, add the following to
" your .vimrc.before.local file:
" let g:spf13_no_autochdir = 1
So just add that last line (without the comment-marker quote) to your .vimrc and you'll get rid of the automated directory change.
I note that neither method in my other answer would have worked, because the plugin author for whatever reason decided not to use the built-in option, and also not to put their autocmd in a group. Naughty, naughty!
I solved this according to Ben's second answer.
spf13 loads configuration files in order as follows.
.vimrc.before - spf13-vim before configuration
.vimrc.before.fork - fork before configuration
.vimrc.before.local - before user configuration
.vimrc.bundles - spf13-vim bundle configuration
.vimrc.bundles.fork - fork bundle configuration
.vimrc.bundles.local - local user bundle configuration
.vimrc - spf13-vim vim configuration
.vimrc.fork - fork vim configuration
.vimrc.local - local user configuration
if !exists('g:spf13_no_autochdir') check is done at (7), so let g:spf13_no_autochdir = 1 should be loaded before that.
I put it in .vimrc.before.local, and it works as expected.
There are two ways this could be happening.
The most likely, is that this "spf13" configuration includes set autochdir. To find out whether this is the case, start up Vim normally, and type :verbose set autochdir? and press Enter. This should tell you IF autochdir is set and WHICH FILE set it to that value.
If autochdir is set, then you only need to set up a VimEnter autocmd, or stick a file in ~/.vim/after/plugin, to turn it off again after spf13 loads.
If autochdir is NOT set, then probably an autocmd is setting your directory for you. If there is a plugin option in SPF13 to turn it off, then do that. If not, you'll need to find where in the plugin the directory is getting changed. If you're lucky, the autocmd will be in an augroup by itself, and you can then remove that autocmd with :au! GroupName. This command can be in the same places; a VimEnter autocmd, or a file in ~/.vim/after/plugin.
Related
In a lua-script (for Domoticz # Raspberry) I apply the following script-segment to generate an htm-file and to put it in the designated folder.
Line02text till Line30text are variables which are dynamically filled elsewhere in the lua-script.
file = io.open("/home/pi/domoticz/scripts/lua/XXXXX.htm", "w+")
-- Opens a file named XXXXX.htm (stored under the designated sub-folder of Domoticz)
-- in append mode
-- write lines to opened file
file:write("SOF<br>")
file:write(Line02text .. "<br>")
file:write(Line03text .. "<br>")
....
file:write(Line29text .. "<br>")
file:write(Line30text .. "<br>")
file:write("EOF<br>")
file:close() -- closes the open file
All seems OK, because the htm-file appears as planned.
Next steps would be to copy the file to different folder, open in browser, etc..
But Owner of the htm-file is 'root' and Permission is 0640.
For further application Owner should be different, and Permission e.g. 777.
Trying manual change or use of chmod results in report 'Permission denied' by server.
Question:
How to set (as result of the lua-script) different Owner and other Permission for the htm-file?
Lua's target is to be as portable as possible, and ownership/permissions management is very os-specific. There's no embedded functions to handle that.
You'll need to expose some native function that will do what you need with files' permissions. Or use some already existing library for that, like maybe lua-fs: (https://github.com/clementfarabet/lua-fs-0.3)
I'm asking about setting a default editor for Pry to use. I'm working on a Rails
app. I created a file named ".pryrc" immediately inside my working directory.
In this file, I wrote this line of code (based on what I read on Github :
Pry.config.editor = proc { |file, line| "sublime +#{line} #{file}" }
This doesn't seem to work. when I try the command ".sublime company.rb", I 'd get
this error:
Error: there was a problem executing system command: sublime company.rb
Can someone tell me what I'm doing wrong please?
Change the configuration to:
Pry.config.editor = proc { |file, line| "sublime #{file}:#{line}" }
You start the editor in Pry by using the edit command.
For example to open test.rb at line 30 use:
edit test.rb:30
See here for more details
For those who have the same problem as mine.Perhaps, you have trouble launching the editor even outside Pry. First thing, make sure to check if the sublime command exists in ur PATH. if not, you probably need to create a symlink between the command and the corresponding path to your app within /usr/local/bin. For more information, see here.
I have my doxygen in my /utils directory, and my source is in another directory in the root(/code_with_doxygen), how could i make a relative path name for that since it's in a repository that will be on different places on other computers. I can't document the whole root because i don't want the directory /code_without_doxygen build too.
the project tree looks like this:
root
utils
code
code_with_doxygen
code_without_doxygen
documentation
right now i have the settings, but that doesn't seem to work:
FULL_PATH_NAMES = YES
STRIP_FROM_PATH = ../
i can't seem to figure it out with: Relative files paths in doxygen-generated documentation
The relative paths depend on the directory from which directory you are executing doxygen. For example if you have the following project tree:
+ project_root
+ documentation
+ config
- doxyfile
+ pictures
+ output
- run_doxygen.bat
+ code
+ code_with_doxygen
+ code_without_doxygen
In this case all relative paths have they root in the folder "documentation" because you are running the script "run_doxygen.bat" from this folder. So you would set the INPUT tag in the "doxyfile" to
INPUT = ./../code
and the OUTPUT_DIRECTORY tag in the doxyfile to
OUTPUT_DIRECTORY = ./output
The misleading thing is that even if the doxyfile is in the subfolder "config" the paths are NOT relative to the location of the doxyfile because the paths are relative to the location from where doxygen is called. In this case it is the folder "documentation" because this is the location of the script which is calling doxygen.
Doxygen allows for including files into doxyfile. You can generate a file using a script before actually calling doxygen. The content of this file has to look like this:
INPUT += path1
INPUT += path2
...
You seem to to run Linux, I don't know the correct bash-commands.
The file has to be integrated into your doxyfile:
INPUT = (project path)
#INCLUDE = generated filename
This will lead to doxygen using the content of your generated file.
#gmug was right. Don't forget to add comment blocks in your code as specified by doxygen For python I needed to add this: """#package docstring""" at the beginning of the file.
I have been able to use relative paths in my doxygen.cfg file by setting INPUT to a string or set of strings. For example:
INPUT = "." "src"
will tell doxygen to look in both the current directory and its subdirectory, $HERE/src.
Let's say I have x.y file in /mydir/a/b (on Linux)
When I run waf, it does not find the file.
def configure(context):
pass
def build(build_context):
build_context(source='/mydir/a/b/x.y',
rule='echo ${SRC} > ${TGT}',
target='test.out')
Result: source not found: '/mydir/a/b/x.y' in bld(features=[], idx=1, meths=['process_rule', 'process_source'] ...
Ok, maybe you want a relative path, Waf? And you are not telling me?
def build(context):
path_str = '/mydir/a/b'
xy_node = context.path.find_dir(path_str)
if xy_node is None:
exit ("Error: Failed to find path {}".format(path_str))
# just refer to the current script
orig_path = context.path.find_resource('wscript')
rel_path = xy_node.path_from(orig_path)
print "Relative path: ", rel_path
Result: Error: Failed to find path /mydir/a/b
But that directory exists! What's up with that?
And, by the way, the relative path for some subdirectory (which it can find) is one off. e.g. a/b under current directory results in relative path "../a/b". I'd expect "a/b"
In general there are (at least) two node objects in each context:
- path: is pointing to the location of the wscript
- root: is pointing to the filesystem root
So in you case the solution is to use context.root:
def build(context):
print context.path.abspath()
print context.root.abspath()
print context.root.find_dir('/mydir/a/b')
Hmm, looks like I found an answer on the waf-users group forum, answered by Mr. Nagy himself:
The source files must be present under the top-level directory. You
may either:
create a symlink to the source directory
copy the external source files into the build directory (which may cause problem if there is a structure of folders to copy)
set top to a common folder such as '/' (may require superuse permissions, so it is a bad idea in general)
The recommendation in conclusion is to add a symlink to the outside directory during the configuration step. I wonder how that would work, if I need this on both, Linux and Windows...
Just pass the Node to the copy rule instead of passing the string representing the path:
def build(build_context):
source_node = build_context.root.find_node('/mydir/a/b/x.y')
build_context(source=source_node,
rule='echo ${SRC} > ${TGT}',
target='test.out')
Waf will be able to find the file even if outside of the top level directory.
I'm using aapt tool to remove some files from different folders of my apk. This works fine.
But when I want to add files to the apk, the aapt tool add command doesn't let me specify the path to where I want the file to be added, therefore I can add files only to the root folder of the apk.
This is strange because I don't think that developers would never want to add files to a subfolder of the apk (res folder for example). Is this possible with aapt or any other method? Cause removing files from any folder works fine, and adding file works only for the root folder of the apk. Can't use it for any other folder.
Thanks
The aapt tool retains the directory structure specified in the add command, if you want to add something to an existing folder in an apk you simply must have a similar folder on your system and must specify each file to add fully listing the directory. Example
$ aapt list test.apk
res/drawable-hdpi/pic1.png
res/drawable-hdpi/pic2.png
AndroidManifest.xml
$ aapt remove test.apk res/drawable-hdpi/pic1.png
$ aapt add test.apk res/drawable-hdpi/pic1.png
The pic1.png that will is added resides in a folder in the current working directory of the terminal res/drawable-hdpi/ , hope this answered your question
There is actually a bug in aapt that will make this randomly impossible. The way it is supposed to work is as the other answer claims: paths are kept, unless you pass -k. Let's see how this is implemented:
The flag that controls whether the path is ignored is mJunkPath:
bool mJunkPath;
This variable is in a class called Bundle, and is controlled by two accessors:
bool getJunkPath(void) const { return mJunkPath; }
void setJunkPath(bool val) { mJunkPath = val; }
If the user specified -k at the command line, it is set to true:
case 'k':
bundle.setJunkPath(true);
break;
And, when the data is being added to the file, it is checked:
if (bundle->getJunkPath()) {
String8 storageName = String8(fileName).getPathLeaf();
printf(" '%s' as '%s'...\n", fileName, storageName.string());
result = zip->add(fileName, storageName.string(),
bundle->getCompressionMethod(), NULL);
} else {
printf(" '%s'...\n", fileName);
result = zip->add(fileName, bundle->getCompressionMethod(), NULL);
}
Unfortunately, the one instance of Bundle used by the application is allocated in main on the stack, and there is no initialization of mJunkPath in the constructor, so the value of the variable is random; without a way to explicitly set it to false, on my system I (seemingly deterministically) am unable to add files at specified paths.
However, you can also just use zip, as an APK is simply a Zip file, and the zip tool works fine.
(For the record, I have not submitted the trivial fix for this as a patch to Android yet, if someone else wants to the world would likely be a better place. My experience with the Android code submission process was having to put up with an incredibly complex submission mechanism that in the end took six months for someone to get back to me, in some cases with minor modifications that could have just been made on their end were their submission process not so horribly complex. Given that there is a really easy workaround to this problem, I do not consider it important enough to bother with all of that again.)