I'm using this in my generator
this.fs.copy(this.templatePath('index.html'),this.destinationPath('index.html') );
I want it to skip the overwrite confirmation everytime it finds a confilict (like force overwrite option)
This is not possible. Yeoman will always ask the user for confirmation before overwriting a file. This is a contract the tool takes with its users: it won't overwrite a file without their acknowledgement.
As a user, if you trust your generator, you can run it with the --force flag to automatically overwrite the conflicting files.
If this is a must to do, you can still force overwriting files by using fs.copyFile(), fs.writeFile() or fs.writeFileSync() function from fs. both functions write data to a file, replacing the file if it already exists.
const yosay = require("yosay");
....
fs.writeFile(filePath, fileContent, 'utf8', err => yosay(err));
If you get error File already exists, you may need to set explicit write flag in the the third param to make it work:
fs.writeFile(filePath,fileContent,{encoding:'utf8',flag:'w'}, err => yosay(err));
OR
const fs = require('fs');
// destination.txt will be created or overwritten by default.
fs.copyFile('source.txt', 'destination.txt', (err) => {
if (err) throw err;
console.log('source.txt was copied to destination.txt');
});
Related
It's my first time using Electron JS and nodejs. I've built a small app that reads some records from a database and updates them. Everything is working fine. I have a config file with the database credentials but when I build a portable win app, I cannot figure out how to read the config file that I would like to place next to the exe. I would like to have easy access to the file, so I could run the same app on different databases.
Can anyone tell me if what I want is possible and how? I already tried to get the exe location but I couldn't. I also read a lot of topics here but nothing seems to solve my problem (I might be doing something wrong).
I'm using electron-builder to build my app.
Thanks in advance.
Edit #1
My Config file is
{
"user" :"X",
"password" :"X",
"server":"X",
"database":"X",
"options":
{
"trustedconnection": true,
"enableArithAbort" : true,
"trustServerCertificate": true
}
}
This is what I've and works when I run the project with npm start
const configRootPath = path.resolve(__dirname,'dbConfig.json');
dbConfig = JSON.parse(fs.readFileSync(configRootPath, { encoding: 'utf-8' }));
However, when I build it, the app is looking for the file in another location different from the one where the executable is.
Use of Electron's app.getPath(name) function will get you the path(s) you are after, irrespective of which OS (Operating System) you are using.
Unless your application writes your dbConfig.json file, it may be difficult for your user to understand exactly where they should place their database config file as each OS will run and store your application data in a different directory. You would need to be explicit to the user as to where to place their config file(s). Alternatively, your application could create the config file(s) on the user's behalf (automatically or through a html form) and save it to a location 'known' to the application.
A common place where application specific config files are stored is in the user's application data directory. With the application name automatically amended to the directory, it can be found as shown below.
const electronApp = require('electron').app;
let appUserDataPath = electronApp.getPath('userData');
console.log(appUserDataPath );
In your use case, the below would apply.
const electronApp = require('electron').app;
const nodeFs = require('fs');
const nodePath = require('path');
const configRootPath = nodePath.join(electronApp.getPath('userData'), 'dbConfig.json');
dbConfig = JSON.parse(nodeFs.readFileSync(configRootPath, 'utf-8'));
console.log(configRootPath);
console.log(dbConfig);
You can try electron-store to store config.
Electron doesn't have a built-in way to persist user preferences and other data. This module handles that for you, so you can focus on building your app. The data is saved in a JSON file named config.json in app.getPath('userData').
I am using flutter_archive 4.0.1 (just updated to 4.1.1) and attempting to unzip a file into an existing directory.
My scenario is that I am backing up this folder, sending to a web server, then at some point, I will want to restore into the same folder. This folder will have many files that are the same filenames as in the zip. I need to overwrite the local files with the ones in the zip.
This works perfect on Android. iOS has always had problems when it comes to working with Zip files.
The extractToDirectory does not have an overwrite switch, so I attempted to use the onExtracting, to check if the file already exists locally, delete the local one, then allow the zip one to take its place.
The problem I am experiencing is that to check if it exists, and to delete, I have to use a Future, but as they are async, I cannot get them to synchronise.
Here is what I have tried.
if (Platform.isIOS) {
await ZipFile.extractToDirectory(
zipFile: zipFile,
destinationDir: destinationDir,
onExtracting: (zipEntry, progress) {
exists(zipEntry.name).then((value) {
if (value) {
deleteFile(zipEntry.name).then((value) {
return ZipFileOperation.includeItem;
});
} else {
return ZipFileOperation.includeItem;
}
});
return ZipFileOperation.includeItem;
}
);
}
Both exists and deleteFile are local Futures, that uses the File functionality.
What I have tried, is that the zipEntry.name will be the same as the file I need to overwrite, so this aspect should work fine. It is now just trying to make things work in order.
The Android version is the same, apart from it does not have the onExtracting functionality.
Not sure if you have found the answer or even if there is a good answer. I ran into this issue myself, and it seems the alternative is delete the target dir before unzipping. There seems no override option for unzip. Here is some snip bits about deletion (as also suggested by the package's unit test code):
final _appDataDir = Directory.systemTemp; //from dart.io
final destinationDir = Directory("${_appDataDir.path}/unzip");
if (destinationDir.existsSync()) {
print("Deleting existing unzip directory: ${destinationDir.path}");
destinationDir.deleteSync(recursive: true);
}
Hope this solution helps others who may have similar issues.
I'm using Grails 2.5.6 to store uploaded images to folder on a server.
The following are my code to store the image
mpr.multiFileMap.file.each{fileData->
CommonsMultipartFile file = fileData
File convFile = new File(file.getOriginalFilename());
file.transferTo(convFile);
/** Processing File **/
File uploadedFile = new File("${directory}${generatedFileName}.${extension}")
convFile.renameTo(uploadedFile)
}
I have no problem running on development (MacOSX High Sierra)
But when i deployed on production (Ubuntu 14.04 server), i could not save the file outside CATALINA_HOME directory.
I have checked the permission and ownership of the destination directory, but still, the directory was created but the file was never stored.
For Example, i've tried to store the file on /home/tomcat/ directory (/home directory was in separate partition with tomcat which stored it /var), the directory was created, but the file was never stored.
When i put the destination directory within CATALINA_HOME folder, everything works fine. But this was not the scenario i want to do.
You say your destination directory is on another partition, so maybe another filesystem is used on this partition.
Or if you look on the javadoc of the renameTo method it is said :
Many aspects of the behavior of this method are inherently
platform-dependent: The rename operation might not be able to move a
file from one filesystem to another, it might not be atomic, and it
might not succeed if a file with the destination abstract pathname
already exists. The return value should always be checked to make
sure that the rename operation was successful.
...
#return true if and only if the renaming succeeded;
false otherwise
Thus I think the renameTo method is not able to move the file, don't know why but you can rewrite your code like this :
mpr.multiFileMap.file.each{fileData->
CommonsMultipartFile file = fileData
File uploadedFile = new File("${directory}${generatedFileName}.${extension}")
// String originalFilename = file.getOriginalFilename()
// you can store originalFilename in database for example
if(!uploadedFile.getParentFile().exists()) {
uploadedFile.getParentFile().mkdirs()
// You can set permissions on the target directory if you desired, using PosixFilePermission
}
file.transferTo(uploadedFile)
}
I have this case. I need to grep a file for some RegEx and the result string (or array of strings) I need to save to variable for later use. And this has to be achieved using Gulp.
It should look like this in my idea:
var line;
gulp.task('grep', function(callback) {
line = someCoolSyncFunction('/needle/', './haystack.txt');
callback();
});
gulp.task('useIt', ['grep'], function() {
console.log(line);
});
Important is this someCoolSyncFunction to be synchronous and to handle file on physical/virtual file system, not the Vinyl file.
Is there a way to do this using Gulp? Or any other approach to achieve similar effect?
PS: to explain the reason, I need to extract version number from Debian package changelog and insert it to configuration file inside the package during the build process.
Thanks a lot.
Vit
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.)