I have a configure script to set up some paths for my R package during installation. I wish to edit a file based on some conditions. Is there any way to edit a file from within the configure.ac? It would be great if the solution is provided for all operating systems.
Is there any way to edit a file from within the configure.ac?
configure.ac is not executable, but I suppose you mean that you want the configure script generated from it to edit a file. The configure script is a shell script, and you can cause arbitrary shell code to be included in it, more or less just by including that code at the corresponding point in configure.ac.
The question, then, is how you would automate editing a file with a shell script. There is a variety of alternatives, but sed is high on my list. You will find it on every system that can support Autoconf configure scripts, because such scripts use it internally.
On the other hand, this sort of thing is one of the main activities of a configure script, in the form of creating files (especially makefiles, but not limited to those) from templates. You should consider building your target file of interest from a template in this way, instead of making custom-programmed edits to a file packaged in your program distribution. This would involve
setting output variables containing the chosen content for the parts of the file that need to be configured;
designating the target file as one for configure to build; and
providing the template, maybe by taking a complete example file and replacing each variable part with a reference to the appropriate #output_variable#.
Related
I have a problem. Universally, my experience working in Unix systems has been that, by the time you are ready to place an executable "thing" in a bin folder for global access, you have decided to #! the file with the requisite interpreter:
#!/bin/awk
#!/bin/bash
#!/bin/perl
#!/bin/python3.8
#!/bin/whatever
And, although it is fine to have clutter at the local scope, when one places an executable in the bin folder, it should have:
A POSIX CLI interface
No discernible language tags or what have you
This is because it is now intended to be used for difficult work that requires forgetting about the details of this or that language: one now needs to think in terms of the functions as if the composable units are part of a consistent language, rather than a dozen different languages from a dozen different expert contributors.
This is the "genius" of the Unix/Linux/Posix architecture.
Anyways, when structuring my python projects, the end game is copying python executables to a global source on the path -- whether that "global" source is a pretend global source in my home directory (i.e., ~/.mytools/bin or the actual global path, /usr/bin or something like that -- and generally I want my python executables to have the same "game feel" as C executables, perl executables, BASH/ZSH/etc. executables.
In that vein, I knock off the extensions from my scripts and executables when they go in the bin. There is no need to know, from my usage perspective, what anything is made of when I go to use it.
However, streamlit requires me to re-append the .py to the file in the global path in order to run with streamlit run. This is a case of the library reaching up out of its useful value and holding me hostage, from my perspective, unless I violate best practices when extending the bin folder with python executables.
This means I have to create special logic to handle just streamlit, and that is really a kerfluffle. I have to either: change the way I handle all executables, or hardcode just the executable that will be run with streamlit. That means that, all of a sudden, I have an arbitrary name in my meta-control code for my project.
That is bad. Why? because I have to remember that I did it, and remember to change it if I change the executable name. I also have to remember to add to it if I add another streamlit executable.
Alternatively, I can copy all my exes made with python into the root bin folders with their .py extensions, which is not what I wanted to do.
How does one bypass this issue in streamlit?
If bin/sometool needs to be invoked with Streamlit via streamlit run bin/sometool, it seems like you're already exposing "meta-control code" to users of your bin script, right?
Instead, would this solve your problem?
bin/sometool:
#!/bin/bash
DIR=$(dirname "$0")
streamlit run "$DIR"/the_actual_script.py
(Where the_actual_script.py sits inside bin, but has chmod -x so that it's not directly executable.)
I am using scalapact for CDC test.
My tests are running fine and the pact file is generated under target>pacts folder.
I have another folder "files" where I want those pact files to be generated after running the pact tests.
Is there any way I configure the default path for pact files?
This is an area that needs some attention in Scala-Pact, however, someone kindly did a PR for us a while ago that lets you set an environment variable called pact.rootDir.
In practice, on linux/mac that variable is a bit tricky to set because of the ., so exporting it or just using -Dpact.rootDir="<my desired path>" in the command arguments doesn't seem to work. Instead, you need to do this:
env "pact.rootDir=<my desired path>" bash. I haven't tried this on Windows so I don't know if you'd have the same issue.
I've just raised an issue to try and make this easier in the future:
https://github.com/ITV/scala-pact/issues/101
As an alternative, note that the pact directory is really kind of a scratch/tmp area to allow Scala-Pact to compile it's output. If you're running this as part of a build script, you may just want to add a step to copy the assets to a new location once they've been generated.
Also, for some reason we made reading from a directory way easier than writing to one. If you need to read from a dir such as during verification, you can just add --source <my desired path> on the command line.
Hope that helps.
When I am trying to copy the file 'Output.xml' from parent folder to target folder, it is not being copied properly i.e: the file size, in the target folder, is different. I am executing the keyword to copy files in my 'Suite Teardown'. Any solution for the issue.
Code written to copy files:
OperatingSystem.Copy Files ${sProjectPath}//output.xml ${sFinalFolder}
The problem is that while the test is running, the output file doesn't exist. It can't exist during suite teardown, because the result of the suite teardown must be part of the log.
If you need the log in another folder, the simplest solution is to tell robot to write it there initially, with the command line option --output or --outputdir.
If you cannot use --output, perhaps the simple solution is to create a script that runs your tests, and then copies the file after it runs. This is mentioned in the user guide in the section titled Creating start-up scripts.
A slightly more complex solution is to use a listener which copies the file in the done method.
Robot run reports are created at the end by robot-framework tool. Hence complete result/report files doesn't exist even in suite teardown.
Best practice would be providing --ouput argument with desired output dir.
More detail you can find from user guide
Robot framework user Guide under section 3.5.1
Note:
The command line option --output (-o) determines the path where the output file is created relative to the output directory. The default name for the output file, when tests are run, is output.xml.
Alternative way is use to rebot command and act on the output file generated by robot run.
When post-processing outputs with Rebot, new output files are not created unless the --output option is explicitly used.
Whether or not it can be done from Robot Framework script, the question is it should be done from Robot Script. These files could be locked and or changed by the current Robot Framework process. If not today, this could well be a part of any future change in this area.
With this perspective I can only recommend to copy these files prior to the start of Robot Framework, and not after. This ensures that the contents of these files are not changed and are fit for the purpose you have in mind.
As these types of actions are typically not part of a Test Case scenario I consider them to be part of the overarching Orchestration. This includes fetching the right version of the test script from version control software, starting Robot Framework, communicating results (ex. email) and safeguarding the test evidence (Log files and other files).
In general these are standard step functionality in a CI tool like Jenkins, Travis CI or Bamboo (to name a few). Even if you have only started on this path, separating this kind of logic from your test script will save you a lot of effort later on.
looks like that Copy Files Kw does not copy the content of output.xml during Teardown ,although it creates file with samename. As A.Kootstra suggested it could be a limitation currently.
Alternative:
in a separate robot script you can rename the file 'output.xml' generated from first script and then can run below command
Copy Files
${sProjectPath}//output.xml ${sFinalFolder}
This copies the whole content
I'm new to R and frankly the amount of documentation is overwhelming, and I haven't been able to find the answer to this question.
I have created a number of .R script files, all stored in a folder that I can access on my server (let's say the folder is, using the Windows backslash character \\servername\Paige\myscripts)
I know that in R you can call each script individually, for example (using the forward slash required in R)
source(file="//servername/Paige/myscripts/con_mdb.r")
and now this script, con_mdb, is available for use.
If I want to make all the scripts in this folder available at startup, how do I do this?
Briefly:
Use your ~/.Rprofile in the directory found via Sys.getenv("HOME") (or if that fails, in R's own Rprofile.site)
Loop over the contents of the directory via dir() or list.files().
Source each file.
as eg via this one liner
sapply(dir("//servername/Paige/myscripts/", "*.r"), source)
but the real story is that you should not do this. Create a package instead, and load that. Bazillion other questions here on how to build a package. Research it -- it is worth it.
Far the best way is to create a package! But as first step, you could also create one r script file (collection.r) in your script directory which includes all the scripts in a relative manner.
In your separate project scripts you can than include only that script with
source(file="//servername/Paige/myscripts/collection.r", chdir = TRUE)
which changes the directory before sourcing. Therefore you would have only to include one file for each project.
In the collection file you could use a loop over all files (except collection.r) or simply list them all.
Slowly going crazy with this one, I am trying to inject Bamboo variables into a text file. I have tried many combinations, but to no avail, cannot seem to get my variable to be replaced during the Atlassian Bamboo build process. I'm running Bamboo on Windows.
Any ideas? This is simply a .txt file that is sent along with my build artifacts.
Whilst not ASP.NET specific, I would eventually like to replace some strings in my Web.config file.
As you can see from the output of my vartest.txt file, no variable combinations are being replaced.
%bamboo.test.variable%
%BAMBOO.test.variable%
%BAMBOO.TEST.VARIABLE%
%BAMBOO_TEST_VARIABLE%
%bamboo_test_variable%
${bamboo.test.variable}
%test_variable%
%TEST_VARIABLE%
%TEST.VARIABLE%
This is my setup (according to the documentation they should be accessible via %BAMBOO_TEST_VARIABLE%):
Those variables are only used for replacing task configuration values or accessing them as environmental variables scripts, they are not substituted in all or any of your source files.
You could run a script that does the replacement using some command-line text tool. See How can you find and replace text in a file using the Windows command-line environment? for some examples.
Then in the script, you can replace ${bamboo.CONNSTRING_PASSWORD} (or whatever format you like) in web.config with the environment variable %BAMBOO_CONNSTRING_PASSWORD%.