I have defined /tmp/ as my source directory. I want to backup only in1/ and in2/ subfolders from it. What lines do I need in profile's exclude file?
/tmp/a
├── in1
│ └── in.txt
├── in2
│ └── in.txt
└── out.txt
According to duplicity man page's dir/foo example, I tried:
+ in1/
+ in2/
- **
But that did not work and I got error as:
Reading globbing filelist /path/to/duply_profile/exclude
Fatal Error: The file specification
in1/
cannot match any files in the base directory
/tmp
Useful file specifications begin with the base directory or some
pattern (such as '**') which matches the base directory.
better use up-to-date man page from duplicity's website https://duplicity.us/stable/duplicity.1.html#file-selection
not sure why the example relative paths is in there, but as the error states you will need something along the lines
+ /tmp/in1/
+ /tmp/in2/
- **
feel free to post a bug ticket on https://gitlab.com/duplicity/duplicity/-/issues so maybe someday some kind soul would make it work with relative paths.
I figured that the following specification work:
+ **in1/
+ **in2/
- **
Related
I've been trying to figure out best practices on implementing environment variables for API configurations in Svelte App. As far as I know, We have to use either Vite or Svite to make it work. Can anyone help me find a solution please ??
This is how I did it but I bet there are other good practices
I make use of dotenv and $lib provided by SvelteKit.
Below are my folder structure and related js:
├── sveltekit-project/ // Root
| ├── src/
| | ├── lib/
| | | ├── env.js
| | | ├── other.js
| | | ...
| | |
| | ├── routes/
| | | ├── main.svelte
| | | ...
| | ├── app.html
| | ...
| ├── .env
/** /src/lib/env.js **/
import dotenv from 'dotenv'
dotenv.config()
export const env = process.env
/** /src/lib/other.js **/
import { env } from '$lib/env'
const secret = env.YOUR_SECRET
By the way, I recommend you reading the "How do I use environment variables?" part in SvelteKit FAQ. It seems very relevant to what you concern, but I am afraid it means some workarounds are needed instead of the VITE_* variables..
There seems to be some confusion around the security issues, but it's actually quite simple.
If you want to use insensitive information, proceed like this:
create an .env and/or .env.local, .env.production file, read more here https://vitejs.dev/guide/env-and-mode.html#env-files
name your variable VITE_<some name> for example VITE_API_URL to store where your backend location is. That's not sensitive information so it's ok to expose this through your svelte app to the internet.
you can then access this directly inside of the script tags in svelte like this: import.meta.env.VITE_API_URL
If you have sensitive information:
Then you shouldn't expose it in a svelte client... PLEASE don't do something like suggested in Saad's answer and expose your API key to the public! Instead you'll need a server to securely hold that information, but how to setup a server is then again a different topic.
Warning
The VITE_ prefix would expose sensitive information to client side! More info
Normally, I'd simply delete this answer, but its clear that the whole import.meta.env.VITE_SECRET_PASSWORD is not a clever design. What is the point of using a .env variable that is not secure, per the security note warning at https://vitejs.dev/guide/env-and-mode.html#env-files ??
As a developer, my expectation is that I can use .env variables to store secure information.
Let this answer stand as a warning: Do not do this.
My original response below:
I spent some time struggling here..
Environment Variable file, must be named .env:
VITE_SENDGRID_API_KEY=SG.9999999999....999999999999
I spent way too much time to figure out that sendgrid.env as a filename will not work.
I added a file to the /src/lib directory called env.js. Here are the complete contents of that file:
export const ENV_OBJ = {
SENDGRID_API_KEY: import.meta.env.VITE_SENDGRID_API_KEY,
TEST: "test, test, test"
};
And then when I need it elsewhere...
import { ENV_OBJ } from '$lib/env'
// console.log("API Key.test: ", ENV_OBJ.TEST);
sgMail.setApiKey(ENV_OBJ.SENDGRID_API_KEY);
I'm using SvelteKit, Javascript, etc... No extra dotenv. Keep it simple, make it easy.
Make sure all your environment variables start with the prefix "VITE_".
Example:
VITE_API_KEY=8465313163463435434353535
Include your variable in the Svelte file using the syntax "import.meta.env.VARIABLE_NAME".
Example:
headers: {
"X-RapidAPI-Key": import.meta.env.VITE_API_KEY
}
And that's it. Hope that helps.
Summary
I'd like to reduce the number of types when formatting.
Status quo
I am using Bazel to manage C++ project. Below is the simplified structure of the project.
❯ tree
.
├── bin
│ ├── BUILD.bazel
│ └── format.sh
├── README.md
├── src
└── WORKSPACE
Now, I'd like to format all files in src (off course, I have test in my real project) by bin/format.sh.
However, it really bothers me to type the long command below. Do you know how to make it easier?(If it is possible to change the command tobazel run bin:format, that's perfect.)
I think adding some codes in bin/BUILD.bazel would help, but I don't have any idea.
bazel run --run_under="cd $PWD &&" bin:format # format source codes
contents of files
sh_binary(
name = "format",
srcs = ["format.sh"],
)
#!/usr/bin/env sh
buildifier -r .
find . -iname *.h -o -iname *.cc | xargs clang-format -i -style=Google
I think what you are doing is fine. I would just define an alias as in
alias clang-fmt='bazel run --run_under="${PWD}" //bin:format'
You could also not use the --run_under option, and pass the directory to the program:
alias clang-fmt='bazel run //bin:format -- "${PWD}"'
and update the script
find $1 -iname *.h -o -iname *.cc | xargs clang-format -i -style=Google
I have a .dockerignore file and I'm trying to allow Docker to upload only *.json files but from any of subfolders.
For example, for the next files structure:
public/readme.md
public/subfolder/a.json
public/subfolder/b.json
public/other/c.json
public/other/file.txt
I'm expecting to see only json files in the image:
public/subfolder/a.json
public/subfolder/b.json
public/other/c.json
Of course they must be located in the same directories as in original source.
I tried several ways but didn't succeed.
UP: I don't know how many subfolders will be created in the public/ directory and how deep will be the directories structure.
I think you can achieve what you want by relying on one such .dockerignore:
public/*
!public/subfolder
public/subfolder/*
!public/other
public/other/*
!**/*.json
The tricky thing is that the first line of this file is public/* but not public nor * (otherwise the !... subsequent lines won't work).
Note also that you may want to automate the generation of one such .dockerignore, to cope with possible tree structure changes.
For example:
gen-dockerignore.sh
#!/usr/bin/env bash
{ echo '*' ; # header of the .dockerignore - to be changed if need be
find public -type d -exec echo -en "!{}\n{}/*\n" \; ;
echo '!**/*.json' ; } > .dockerignore
$ ./gen-dockerignore.sh would output the following file:
.dockerignore
*
!public
public/*
!public/other
public/other/*
!public/subfolder
public/subfolder/*
!**/*.json
I'm using nix package-manager on macOS (Sierra).
My intention is to write a nix expression that will install the existing fish nix package along with the Bass fish plugin.
There are no existing expressions in nixpkgs for Bass, but the git repo contains a Makefile. This Makefile attempts to copy files to the $HOME dir. This is a problem as installing files outside of the nix-store is clearly not desirable and $HOME is not set when I build my package.
I can recognise why it's not desirable for nix packages to install files outside of the nix-store - in functional programming terms it's akin to a side-effect. But I'm also not clear on how to solve my problem:
By default Fish requires plugins such as Bass to be installed under $HOME/.config/fish/. Fish does provide a means to customise the config path by specifying the environment variable XDG_CONFIG_HOME. So I was thinking of doing something like this:
Create an expression for Bass patching the Makefile to install the files under $out.
Create an expression that installs fish and uses Bass as a build input. Use wrapProgram to set XDG_CONFIG_HOME pointing to the Bass install path in the nix-store.
Does this sound like the right approach? Are there alternative/better ways of solving this?
Thanks
This is the solution that I have gone with:
Expression for bass:
nix_local/pkgs/fish_plugins/bass/default.nix
{stdenv, fetchFromGitHub}:
let
version = "0.0.1";
in
stdenv.mkDerivation rec {
name = "bass-${version}";
src = fetchFromGitHub {
owner = "edc";
repo = "bass";
rev = "1fbf1b66f52026644818016015b8fa9e0f639364";
sha256 = "12bp8zipjbikasx20yz29ci3hikw0ksqlbxbvi2xgi4g6rmj7pxp";
};
patchPhase = ''
substituteInPlace Makefile --replace \
"~/.config/fish" \
$out/.config/fish
'';
}
Expression for fish_with_config:
nix_local/pkgs/fish_with_config/default.nix
{stdenv, fish, bass, makeWrapper}:
let
version = "0.0.1";
in
stdenv.mkDerivation rec {
name = "fish-with-config-${version}";
src = ./.;
buildInputs = [fish bass makeWrapper];
installPhase = ''
mkdir -p $out/.config/fish/functions
cp -r $src/.config/* $out/.config
cp -r ${bass}/.config/fish/functions/* \
$out/.config/fish/functions/
mkdir -p $out/bin
ln -s ${fish}/bin/fish $out/bin/fish
wrapProgram $out/bin/fish --set XDG_CONFIG_HOME "$out/.config"
'';
}
The Fish program is wrapped in order for it's config to be stored in the nix-store. This enables us to symlink the functions from Bass and also copy any additional config files from the local $src dir. Additional plugins could be symlinked in the same way.
The local src dir for the derivation contains the following files:
pkgs/fish_with_config
├── .config
│ └── fish
│ ├── fishd.8c8590486f8c
│ └── functions
└── default.nix
The .config/fish/fishd.8c8590486f8c file is a "universal variable file" which Fish requires in order to operate. In a standard Fish installation this file is stored under ~/config/fish/ and is created the first time you enter interactive mode. The contents of this file would typically change over time as users interact with Fish settings.
The fish_with_config derivation stores the Fish config in the nix-store, which means it can't be modified at a latter date (not writable). This means all the config settings need to be done upfront as any attempts by the user to modify the settings will result in permission errors - this is obviously a little inconvenient, but not a show stopper for me.
It's probably worth noting that the universal variable file may change with different releases of Fish and as such if I was to build fish_with_config with a newer version of Fish I would first determine it's default content by running fish in a nix-shell and inspecting the auto generated file under ~/config/fish/.
In summary the above works nicely, I have access to bass and any additional user defined functions I choose to "bake in" (pkgs/fish_with_config/.config/fish/functions).
If you see anything that could be improved or handled more idiomatically let me know.
When using pdflatex with -output-directory I run into issues when externalizing tikz figures. While the .md5 files are created where I expect them the command creating the externalized picture files (.pdf, .log, .dpth) fails. My assumption is that this happens because the pdflatex to create these files does not inherit the -output-directory option and thus fails to create the files in the right spot.
This is a minimal example showing the behavior.
main.tex:
\documentclass{minimal}
\usepackage{tikz}
\usetikzlibrary{external}
\tikzexternalize[prefix=tikz/]
\begin{document}
Test externalize in combination with -output-directory
\tikzsetnextfilename{testpicture}
\begin{tikzpicture}
\node {Node};
\end{tikzpicture}
\end{document}
bash:
mkdir -p build/tikz
pdflatex -output-directory build -shell-escape main.tex
error:
===== 'mode=convert with system call': Invoking 'pdflatex
-shell-escape -halt-on-error -interaction=batchmode -jobname
"tikz/testpicture" "\def\tikzexternalrealjob{main}\input{main}"'
======== This is pdfTeX, Version 3.14159265-2.6-1.40.16
(TeX Live 2015/Debian) (preloaded format=pdflatex)
\write18 enabled.
entering extended mode
! I can't write on file `tikz/testpicture.log'.
resulting directory structure (output of tree):
.
├── build
│ ├── main.aux
│ ├── main.auxlock
│ ├── main.log
│ ├── main.pdf
│ └── tikz
│ └── testpicture.md5
└── main.tex
So again, as far as I understand the log file creation fails due to the lack of a tikz directory in the working directory of the pdflatex command executed by the externalization.
Are my assumptions correct? If they are, how should how I should proceed with this?
As far as I have found out the easiest solution is to create a symlink in your main folder to the tikz folder inside build. Like so: ln -s build/tikz .
This was the solution I found in the documentation of another tikz externalizing library.
tikzexternal does not detect the -output-directory argument. Hence you have to modify the call to the compiler of the externalized images and add this argument by your own.
This also holds true for the inclusion of the image. You have to prefix the image here with the path of the output directory.
Those two points can be seen in the following MWE:
\documentclass{minimal}
\usepackage{tikz}
\usetikzlibrary{external}
\tikzexternalize[prefix=tikz/]
\makeatletter
\tikzset{%
external/system call={%
pdflatex %
\tikzexternalcheckshellescape %
-halt-on-error %
-interaction=batchmode %
-output-directory="build" %
-jobname "\image" %
"\texsource"%
},
/pgf/images/include external/.code={%
\includegraphics{build/#1}%
},%
}
\makeatother
\begin{document}
Test externalize in combination with -output-directory
\tikzsetnextfilename{testpicture}
\begin{tikzpicture}
\node {Node};
\end{tikzpicture}
\end{document}
Some additional notes:
You can find the relevant code in pgf/frontendlayer/tikz/libraries/tikzexternalshared.code.tex
If your tex file is in a sub directory or you use -jobname you have to replace "\texsource" with something like "\string\def\string\tikzexternalrealjob{\tikzexternal#realjob}\string\input{path/to/tex/file/\tikzexternal#realjob}"
Edit
There is a shorter way to do this: Instead of setting external/system call, you can also set external/shell escape={-shell-escape\space-output-directory=build}. This will end up in \tikzexternalcheckshellescape.
For both methods (the original and the shorter one) to work with LuaLaTeX, you need \usepackage{shellesc}.
It could be a question with regards to the permissions as well.
Try with
chmod 777 tikz
right after you create the folder.
You could also try to move your main.tex file into the build folder to see if that changes things.
I found that symlinking as suggested by Artemis is indeed the easiest option, i.e.:
mkdir -p build/fig
ln -sf build/fig .
pdflatex -shell-escape -output-directory=build main.tex
Additionally, if you use \tikzexternalize[mode=list and make], you will also notice that the generated build/main.makefile can't be used as is either, because it uses files both in the base folder and in the build folder. To make it work, again, symlinking seems to be the easiest option, this time the file main.figlist (alternative would be copying files or modifying the makefile). The full process now looks as follows:
# Run once to create list of externalize figures:
mkdir -p build/tikz
ln -sf build/tikz .
pdflatex -output-directory=build main.tex
# Build externalized figures:
ln -sf build/main.figlist .
make -f build/main.makefile
# Run again to include externalized figures into document:
pdflatex -output-directory=build main.tex
# Cleanup:
rm tikz main.figlist
Furthermore, if you encounter problems with other packages you may need to also take into account Phobos' answer to ensure that the build directory is also known while building the individual figures, i.e.:
\tikzexternalize[
prefix=tikz/,
mode=list and make,
shell escape={-shell-escape\space-output-directory=build},
]