Rsync fails with exit code 23 only when run from Node - javascript

I am using the rsync module with Node v0.10.22. Rsync exits with code 23 (Partial transfer due to error) when run from Node, but succeeds when run from the same exact shell as the crashed Node process.
Here is the code I am using:
var r = new Rsync()
.flags('a')
.include('*.png')
.exclude('*')
.source(path.join('source/*'))
.destination('target')
.execute(function (err, code, cmd) {
if (err && code === 23) {
console.log('Exited with 23');
console.log(cmd);
}
});
The cmd that is logged is as follows:
rsync -a --include="*.png" --exclude="*" source/* target
When I execute that exact command after Node crashes in the same shell the command returns 0 (no errors, it worked).
I have looked at rsync.js where it spawns the command:
// Execute the command as a child process
var cmdProc = spawn(this.executable(), this.args(), { stdio: 'pipe' });
this.executable() returns 'rsync'. this.args() returns ['-a', '--include="*.png"', '--exclude="*", 'source/*', 'target/'].
What is going on here? Why do I get a different exit code when running from Node as opposed to running in the same shell as where I run Node?
Edit: I set the permissions on each directory to be 777 and I am still getting the same error.

The glob in the source isn't expanded, so rsync tries to find a file named * in the source directory. Change the source to source/.

Related

ShellJs execute CLI command

I'm using codeceptjs with shelljs.
In one of tests I'm invoking go application like this :
const shell = require('shelljs')
shell.exec('./myGoApplication')
When application is started and correctly working I have a CLI that is listening for input from console via keyboard so I can type text and my application is getting it.
But when I execute this command seems its not transferring to the input and application is not invoking commands.
shell.exec('my text')
Does someone know how to make shellJs make command to my CLI waiting for console input?
go cli:
func StartCLI(relay RelayConn) {
go func() {
fmt.Println("[?] To see avaliable commands write /?")
reader := bufio.NewReader(os.Stdin)
for {
text, _ := reader.ReadString('\n')
text = strings.Trim(text, "\n")
switch true {
case strings.HasPrefix(text, "/?"):
fmt.Println(helpText)
default:
relay.Chat("Default Member Simulation chat message")
}
}
}()
}
https://github.com/shelljs/shelljs
As of writing this answer, it is not possible for processes launched via exec to accept input. See issue #424 for details.
From the ShellJS FAQ:
We don't currently support running commands in exec which require interactive input. The correct workaround is to use the native child_process module:
child_process.execFileSync(commandName, [arg1, arg2, ...], {stdio: 'inherit'});
Using npm init as an example:
child_process.execFileSync('npm', ['init'], {stdio: 'inherit'});
Your code should therefore be something like this:
const child_process = require('child_process')
child_process.execFileSync('./myGoApplication', {stdio: 'inherit'})
Setting the stdio option to 'inherit' means that stdin, stdout, and stderr of the child process is sent to the parent processes' (process.stdin, process.stdout, and process.stderr), so you should be able to type in input to your Node.js program to send it to your Go program.
See the documentation on child_process.execFileSync for more deatils.

'.' is not recognized as an internal or external command thrown when used in exec(), but not when run from command line

The following is part of a script that is run using npm run test.
async setup() {
process.env.DATABASE_URL = this.databaseUrl;
this.global.process.env.DATABASE_URL = this.databaseUrl;
await exec(`./node_modules/.bin/prisma migrate up --create-db --experimental`);
return super.setup();}
This throws the following error
Command failed: ./node_modules/.bin/prisma migrate up --create-db --experimental
'.' is not recognized as an internal or external command,
operable program or batch file.
When run from the cmd the command works as expected. What is the correct way to reference the binary file within exec()? I am using windows incase that is relevant.
Solution with help from #derpirscher.
const path = require("path");
const prismaBinary = "./node_modules/.bin/prisma";
await exec(
`${path.resolve(prismaBinary)} migrate up --create-db --experimental`
);

Axosoft/nsfw file monitor doesn’t trigger file changes

The following problem only exists on Windows, on macOS the code below works as expected.
So, I am on Windows 10 (v1909) and installed nsfw in my electron program and can't make it work. I installed it with the following command:
npm install nsfw --save
> nsfw#2.0.0 install C:\Users\daniel\Desktop\my-foo-example\node_modules\nsfw
> node-gyp rebuild
C:\Users\daniel\Desktop\my-foo-example\node_modules\nsfw>if not defined npm_config_node_gyp (node "C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild ) else (node "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" rebuild )
Building the projects in this solution one at a time. To enable parallel build, please add the "-m" switch.
NSFW.cpp
Queue.cpp
NativeInterface.cpp
Controller.cpp
Watcher.cpp
win_delay_load_hook.cc
Creating library C:\Users\daniel\Desktop\my-foo-example\node_modules\nsfw\build\Release\nsfw.lib a
nd object C:\Users\daniel\Desktop\my-foo-example\node_modules\nsfw\build\Release\nsfw.exp
nsfw.vcxproj -> C:\Users\daniel\Desktop\my-foo-example\node_modules\nsfw\build\Release\\nsfw.node
+ nsfw#2.0.0
I call nsfw the following way. I expected "start watching" to be printed, but nothing happens. Also no file changes in the given directory gets printed out. The directory does exist. Am I missing something?
var watcher2;
app.whenReady().then(() => {
createWindow();
nsfw(
"C:\\Users\\daniel\\Desktop\\foo",
function (events) {
console.log(events);
},
{
debounceMS: 250,
errorCallback(errors) {
console.log(errors);
},
}
)
.then(function (watcher) {
watcher2 = watcher;
console.log("start"); <--- get's executed
return watcher.start();
})
.then(function () {
console.log("start watching"); <--- DOES NOT get triggered
// we are now watching dir for events!
});
});
I had a similar issues, especially given the fact that the stop call is part of the example in the repo. However, in your case it seems you don't have a .catch which would reveal the actually underlying error.

NodeJS fs.watch is not reacting to changes inside a Docker Container

The idea of the following code is to react to changes in files inside a folder. When I run this code on my macOS everything works as executed.
let fs = require("fs");
let options = {
encoding: 'buffer'
}
fs.watch('.', options, function(eventType, filename) {
if(filename)
{
console.log(filename.toString());
}
});
Inside a Docker Container on the other hand the code does not react to file changes. I run the code in the following way:
docker run -it --rm --name $(basename $(pwd)) -v $(pwd):/app -w /app node:slim sh -c 'node index'
Is there an option to use with Docker to allow system notifications for file changes?
New answer
Initially i advised Gulp (see bottom of the updated post with old answer). It did not worked because you tried to use it programatically, when Gulp is task runner and have own usage patterns, which i did not described. Since you need something specific, i have very simple, surely working solution for you.
It uses one of modules used by gulp called gaze - module which have approx 1.7m downloads per week. Its working, for sure on every system.
npm install gaze --save
To make it work lets create index.js in your root folder (which will be mounted to your app folder inside of the docker, and then just follow basic instruction given in module README:
var gaze = require('gaze');
// Watch all .js files/dirs in process.cwd()
gaze('**/*.js', function(err, watcher) {
// Files have all started watching
// watcher === this
console.log('Watching files...');
// Get all watched files
var watched = this.watched();
// On file changed
this.on('changed', function(filepath) {
console.log(filepath + ' was changed');
});
// On file added
this.on('added', function(filepath) {
console.log(filepath + ' was added');
});
// On file deleted
this.on('deleted', function(filepath) {
console.log(filepath + ' was deleted');
});
// On changed/added/deleted
this.on('all', function(event, filepath) {
console.log(filepath + ' was ' + event);
});
// Get watched files with relative paths
var files = this.relative();
});
Now lets run your command:
docker run -it --rm --name $(basename $(pwd)) -v $(pwd):/app -w /app node sh -c 'node index'
What we have upon changes - Linux outpud, but this works for Mac OS too.
blackstork#linux-uksg:~/WebstormProjects/SO/case1> docker run -it --rm --name $(basename $(pwd)) -v $(pwd):/app -w /app node sh -c 'node index'
Watching files...
/app/bla was changed
/app/foobar.js was changed
Old answer.
You can do it with gulp.
Gulpfile.js
const gulp = require('gulp');
gulp.task( 'watch' , ()=>{
return gulp.watch(['app/**'], ['doStuff']);
});
gulp.task( 'doStuff', cb => {
console.log('stuff');
//do stuff
cb();
});
So far such approach worked for me (of course you can build much more
complex things, but if find using gulp conventient for different
filesystem tasks).

Detect Browserify broken build before committing/deploying

I'm using Browserify to bundle up my JS before pushing to my Bitbucket repo, and then using Codeship to test the build and push to Heroku.
I'm using Node/Express to serve my app, and in my index.jade I have a <script /> pointing to /dist/index.js.
A couple of times, I've mistakenly pushed my latest code with broken Browserify output, ie. the contents of /dist/index.js will be:
console.error('cannot find module XYZ')
And I've deployed this to my live app. UH OH.
I've put in a very rudimentary test which gets ran on Codeship which I'm hoping should avoid this in the future:
var exit = function() {
process.exit(1)
}
var success = function() {
process.exit(0)
}
var fs = require('fs')
var index
try {
index = fs.readFileSync(__dirname + '/../public/dist/index.js', 'utf-8')
} catch (e) {
exit()
}
if(!index){
exit()
}
var invalid = index.length < 1000
if(invalid){
return exit()
}
success()
I'm just checking if the file exists, and that the contents of the file is over 1000 characters.
Not sure if there's a specific answer to this, but would be a reasonable approach to making sure broken Browserify output never gets committed/deployed?
I haven't used Codeship before, but I have used other similar services. You haven't described how you push - I'm going to assume you're using git.
With git, this becomes easy: write a pre-push hook that will abort the push if something fails. Here's an example from a project I'm working on:
#!/bin/bash
# the protected branches
#
protected_branches='develop master'
# Check if we actually have commits to push
#
commits=`git log #{u}..`
if [ -z "$commits" ]; then
exit 0
fi
current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/\(.*\),\1,')
# is the current branch in the list of protected branchs? if so, then run the
# tests
#
if grep -q "$current_branch" <<< "$protected_branches"; then
# move into the dir containing the tests
#
pushd $(git rev-parse --show-toplevel)/contract >/dev/null
gulp test
RESULT=$?
# back to whatever dir we were in before
#
popd >/dev/null
if [ $RESULT -ne 0 ]; then
echo "-------- Failed Tests"
exit 1
fi
fi
exit 0
This is a modified version of a script I found in this blog post.
Basically, this script checks to see if I'm pushing one of the protected branches and, if so, runs my tests. If those test fail, then the push is aborted.
You could, of course, change the conditions under which the push is aborted. For example, write some code to check & see if your browserify bundle is correct and fail if it's not. You mention checking the length of your bundle - maybe something like length=$(ls -l | cut -c 30-34) and then check the value of length (sorry, I'm not a real bash guru).
The benefit of this approach is that the messed up code never leaves your local machine - you run the test locally and if it fails, the code doesn't get pushed. This is likely to be faster than running in on Codeship's service.

Categories

Resources