I wrote a plugin for babel that relies on the opts.filename and opts.filenameRelative properties. It seems to be working within babel-loader for the purposes of analyzing the adjacent files, but the filename itself seems to be modified.
I'm wondering if theres a way, using babel-loader, to get access to the full source file path to use for generating a legible id and hash.
babel-loader does indeed pass the filename into the transform function. In my particular case, I was preprocessing typescript files with awesome-typescript-loader, and that was messing with the file path.
Related
I want to configure mplayer to look for an edl when playing a video. Specifically, I want it to use "show.edl" when playing "show.mp4", assuming both are in the same directory. Very similar to how it looks for subtitles.
I can add a default edl in the config file by adding the following:
edl=default.edl
And this will look for the file "default.edl" IN THE CURRENT DIRECTORY, rather than in the directory where the media file is. And it isn't named after the media file either, and thus even if it did look in the right place, I'd have one single edl file for every media file in that directory.
Not really what I wanted.
So, is there a way, in the "~/.mplayer/config" file, to specify the edl relative to the input file name?
Mplayer's config file format doesn't seem to support any sort of replacement syntax. So there's no way to do this?
MPlayer does not have a native method to specify strings in the config file relative to the input file name. So there's no native way to deal with this.
There's a variety of approaches you could use to get around that. Writing a wrapper around mplayer to parse out the input file and add an "-edl=" parameter is fairly general, but will fail on playlists, and I'm sure lots of other edge cases. The most general solution would of course be to add the functionality to mplayer's config parser (m_parse.c, iirc.)
The simplest, though, is to (ab)use media-specific configuration files.
pros:
Doesn't require recompiling mplayer!
Well defined and limited failure modes. I.E. the ways it fails and when it fails are easily understood, and there aren't hidden "oops, didn't expect that" behaviors hidden anywhere.
Construction and updating of the edl files is easily automated.
cons:
Fails if you move the media around, as the config files need to full path to the edl file to function correctly.
Requires you have a ".conf" file as well as an EDL file, which adds clutter to the file system.
Malicious config files in the media directory may be a security issue. (Though if you're allowing general upload of media files, you probably have bigger problems. mplayer is not at all a security-hardened codebase, nor generally are the codecs it uses.)
To make this work:
Add "use-filedir-conf=yes" to "/etc/mplayer.conf" or "~/.mplayer/config". This is required, as looking in the media directory for config files is turned off by default,
For each file "clip.mp4" which has an edl "clip.edl" in the same directory, create a file "clip.mp4.conf" which contains the single line "edl=/path/to/clip.edl". The complete path is required.
Enjoy!
Automatic creation and updating of the media-specific .conf files is left as an exercise for the student.
I'm using Scribble to pull in parts of files that are stored in other files (not written in Racket). Reading the files and getting the content in works fine, but I don't know how to figure out where the file that the function is being invoked is in, so the only way to get it to work is to pass in a path relative to the root of the document, which is unpleasant.
i.e., I have a directory structure like:
...
hw/
hwN/
assignment.scrbl
template.EXT
...
And in assignment.scrbl, I want to pull in parts of template.EXT, but currently I have to write hw/hwN/template.ext. It would be a lot nicer to, as I can do with #include-section, be able to write just template.EXT, so that if I rearrange the directories I won't break all of these paths.
This is not really specific to Scribble. In Racket, you would do:
(require racket/runtime-path)
(define-runtime-path template.EXT "template.EXT")
then you can use template.EXT to refer to the file.
For example, in my main.scm file I have (load "util.scm"). util.scm is a file in the same folder as main.scm. Both files are located in ~/documents/myproject/.
Now when I'm in this directory, and I run $ chez-scheme main.scm everything works fine. However, if I'm in my home directory and run $chez-scheme documents/myproject/main.scm it complains, not being able to find the file util.scm. I suppose this is the case because the current directory was my relevant home directory, and as such util.scm is indeed not there, it is actually in documents/myproject/. That being said, I'm used (in other languages) to the functionality of looking these paths up relative to the file containing the instruction to import, and I'd like to have that here as well. I've tried prefixing it by ./ or defining the file as a libary and doing (import (util)) but none of it works outside of documents/myproject/. Is there any way to get this to work as I intend it to?
I assume this is Chez-Scheme-specific. If not I'd prefer an answer that is implementation-neutral.
load is kind of awkward in R5RS since the report states that system interfaces are off topic in the report, but they include load which is a half hearted solution. The report does not say if the load is relative to the current directory or the file the load form originates from so in order to be portable I guess you are required to run your script from the current directory and have your loaded file relative to both.
Since Chez Scheme implements R6RS load is not really the right form to use. R6RS removed load in favor of libraries. You should make your file a library and consult how to install it. In some systems that is just placing the files in the right path, adding library location in configuration or running install script. How one uses the library is the same in all implementations, by using import.
According to Chez documentation you can pass --libdirs to it to give it one or more paths to consider for loading libraries. You can see the paths it scans by evaluating (library-directories)
There are several different ways to accomplish what (I think) you are trying to do, but eventually they all boil down to letting Chez know where to look for things. When given relative paths, include and load use the source-directories parameter to search for the requested file. Libraries have their path automatically prepended to source-directories while they are being loaded or compiled, so if your main.scm were a library definition then it would find util.scm as you expect.
However, it sounds like main.scm isn't a library, it's a top-level program. Unfortunately, Chez doesn't have a command line option to set the source-directories like it does for library directories. That leaves you with a bit less flexibility. Any of the following will work:
Make util.scm a library and invoke Chez with the --libdirs option to let it know where to look for libraries.
Set source-directories and load main.scm from inside the REPL rather than from the command line.
Write a wrapper shell script that does the above by echoing the commands into scheme so you don't have to type it yourself. (Only suitable if you don't also need to then type into the scheme session).
Write a wrapper shell script that cds into your project directory before running scheme (and presumably cds back to the original directory when it's done).
I am using the xmlpoke task in nant and am looking for a way to use a wildcard when addressing the xml file. Right now I have a file path like project\appFiles\project{versionNumber}\fileToUpdate.xml, I would like to use a wildcard so its something like project\appFiles\project*\fileToUpdate.xml so I don't have to update the version number every time.
How do you get it to respect wildcards?
Looking all over the web, it doesn't look like this is possible, and by design. Like copy command (todir), the file path must point to a single file so no wildcards allowed (Found info on copy command, assuming same applies for XMLPoke, but could confirm exactly).
I ended up changing some design stuff so now the version number is easily calculated by the program calling the script, so passing in not an issue anymore.
I'm using Eclipse and Doxygen on a Linux platform. My teams code is controlled with Clearcase. My question is can I use an environment variable as part of the path to excluded?
example: every one on the project has a custom view as part of their path. And I don't want to see that in the documentation.
/view/me/a/b/src/.../...
/view/you/a/b/src/.../...
in each developers view their is an environment variable defined with their view name. ex: $CLEARCASE_ROOT = /view/me
So I'm trying to setup a single Doxygen file for whole team to use..
So I want to do something like EXCLUDE ${CLEARCASE_ROOT}/a/b
Then everybody that generates docs will get the same paths.. Can I do this??
Thanks.
Yes, doxygen supports environment variable expansion in its configuration files, see http://www.doxygen.nl/manual/config.html.
The EXCLUDE option controls which files are parsed by doxygen. It sounds like you want the files to be included, but you want them to be displayed with a relative include path, in that case you probably want to use the STRIP_FROM_INC_PATH option. If there are other absolute paths in the documentation you're attempting to make relative, the STRIP_FROM_PATH option may also come into play.
The syntax is a little different than what you proposed, $() vs. ${}, so you'll want to specify something like:
STRIP_FROM_INC_PATH = $(CLEARCASE_ROOT)/a/b
STRIP_FROM_PATH = $(CLEARCASE_ROOT)