I have an app that generate build folder after building. Each time, the app will delete the whole build folder and add it back with new files inside.
I try to watch this folder change and do something.
nodemon --watch build --exec doSomething
However, this command will only watch if the build folder exists all the time and the file changes inside. It does not work when the whole folder got deleted and added back.
How to use nodemon to watch a folder got deleted and added back with new files with new files inside? Thanks
At least on MacOS, if the -L or --legacy-watch flags are used, nodemon stops working after the watched directory is deleted and fails to work correctly until the nodemon process is killed.
If the -L or --legacy-watch flags are omitted, nodemon works correctly after the watched directory is recreated.
Related
As I understand the directories of each file fossil.exe, repository-file and files (to be versioned) can be in totally different pathes, is that right?
However, I get the following error:
file outside of checkout tree: path_to_file\filename
My structure is as follows:
FOSSIL\fossil.exe
NewFolder\repo.fossil
NewFolder\Subfolder\sample_table.csv
When opening the repo and then running fossil add full_path\sample_table.csv I get the above mentioned error.
A few things:
It doesn't matter where the fossil executable is located, as long as it's somewhere in the search path (otherwise you have to use the full path every time).
It doesn't really matter where the repository file is located either, as long as it doesn't move after you've opened it. (If you do want to move it, close the repository first).
You're missing a work directory. You need to open the repository first, into a work directory (also called the checkout tree). That work directory will be where you'll be working on your files.
In the situation you describe, you'd need to run the following command:
cd <topmost folder of your code>
fossil open NewFolder\repo.fossil
After that, you can do whatever you need in that folder (and its subfolders), and anytime you perform a commit or checkin, the changes you've made will end up in the repository.
fossil add NewFolder\Subfolder\sample_table.csv
fossil commit --comment "Added sample table"
There's usually no reason to close the working directory again; except perhaps if you want to move the repository: you'd then use fossil close to close the working directory, move the repository, and then use fossil open <new_repo_path> from the working directory again.
Note that the repository can be located somewhere else entirely; and also that a single repository can be opened into several different work directories at the same time.
Once in a while I like to send a version of my software to my Ubuntu PPA on Launchpad. To do so, I need to regenerate the source, description, and change files. To do that, I run the following command:
debuild -S -sa -nc -m"alexis#example.com"
The problem is that it spits out all the files one directory up from my main folder. So say I am working on a project named Beautiful, I would see:
projects/
projects/Beautiful/
projects/Beautiful/<source files from my git>
projects/Beautiful_1.2.3~xenial.dsc
projects/Beautiful_1.2.3~xenial_source.build
projects/Beautiful_1.2.3~xenial_source.changes
projects/Beautiful_1.2.3~xenial_source.ppa.upload
projects/Beautiful_1.2.3~xenial.tar.gz
I would like to place all of the source files in a sub-folder such as:
projects/
projects/Beautiful/
projects/Beautiful/<source files from my git>
projects/Beautiful_source/Beautiful_1.2.3~xenial.dsc
projects/Beautiful_source/Beautiful_1.2.3~xenial_source.build
projects/Beautiful_source/Beautiful_1.2.3~xenial_source.changes
projects/Beautiful_source/Beautiful_1.2.3~xenial_source.ppa.upload
projects/Beautiful_source/Beautiful_1.2.3~xenial.tar.gz
Is it possible from the command line or a rule somewhere? Or is the one directory up the only place where debuild will work on that?
https://github.com/ninja-build/ninja/releases
I have downloaded the ninja-win.zip folder and extracted it. When I open it, there is a single .exe file in the entire folder. When I double click it a cmd window flashes for a split second. I have also tried running it as administrator, but the same thing happens. What I don't understand is, what am I expected to do with this .exe file?
You must open a terminal (cmd.exe on Windows) and type something like ninja -f /path/to/buld/file. You may also wish to modify the PATH environment variable so that Windows knows where to find the Ninja executable, depending on your setup.
You can simple download ninja.exe file from this Link
https://github.com/ninja-build/ninja/releases
After that you just have to add the path to your ninja.exe file to your windows environment variables and then you can use ninja commands from anywhere in windows.
1. Open cmd in your Project Directory
2. There are guides on the internet on where to save the Ninja.exe so that it'll be callable in Cmd without specifying directory. Either follow them or:
i, Specify Directory when Calling Ninja. Putting "ninja" in Cmd actually calls Ninja.exe and is the same as something like "C:\users\user1\downloads\Ninja". or:
ii, Save Ninja.exe in the same directory as Project.
3. proceed with rest of the command.
Therefore the Final Command would be:
"C:\users\user\downloads\Ninja.exe" -f "D:\Projects\Project1"
I was working on Android studio (on the Mac) when I got the following message:
Error:Could not read cache value from
'/Users/Friso/.gradle/daemon/2.2.1/registry.bin'.
I don't know what caused it, since I didn't do anything to the build files.
How can I fix this?
Try deleting the /Users/Friso/.gradle directory and rebuild.
In my case, the registry.bin file was empty. However, there was a lock which seemed to be causing the issue. I deleted the lock file - registry.bin.lock from the /Users/varun/.gradle/daemon/2.8/ directory and it worked.
Hope this helps.
It also happened in my Linux environment. Deleting .gradle folder and rebuilding the project worked again.
The gradle directory (or one of its caches) is likely corrupted in some way. The easiest way to proceed is to delete the directory entirely. Navigate to /Users/Friso and run:
sudo rm -r .gradle
sudo rm -r ~/.gradle
This recursively removes the directory and all files within it. The latter is your home gradle cache.
In my case I had stopped the grade in between and turned off my laptop.The next time I opened and ran my gradle it gave error of could not read cache value from registry.bin.
The error was coming in every project of mine.
I did the following:
Go to C:\users\username.gradle\daemon\gradle version and delete registry.bin.lock file.
Hope this will solve your problem.
Delete registry lock file from c:\users{username}.gradle\demon{version} and then build again
I'm creating a simple RPM installer, I just have to copy files to a directory structure I create in the %install process.
The %install process is fine, I create the following folder /opt/company/application/ with the command mkdir -p %{buildroot}/opt/company/%{name} and then I proceed to copy the files and subdirectories from my package. I've tried to install it and it works.
The doubt I have comes when uninstalling. I want to remove the folder /opt/company/application/ and I thought you're supposed to use %{buildroot} anywhere when referencing the install location. Because my understanding is the user might have a different structure and you can't assume that rmdir /opt/company/%{name}/ will work. Using that command in the %postun section deletes succesfully the directories whereas using rmdir ${buildroot}/opt/company/%{name} doesn't delete the folders.
My question is, shouldn't you be using ${buildroot} in the %postun in order to get the proper install location? If that's not the case, why?
Don't worry about it. If you claim the directory as your own in the %files section, RPM will handle it for you.
FYI, %{buildroot} probably won't exist on the target machine.