Wildcard not suppported?

[rogerz]

Got an error when specifying a wildcard pattern in src.

$ grunt rsync:test
Running "rsync:test" (rsync) task
rsyncing dist/* >>> ~/signature-cluster-dist
Shell command was: rsync dist/* rogerz@letsface:~/signature-cluster-dist --rsh "ssh -p 40022" --recursive
ERROR
Error: rsync exited with code 23. rsync: link_stat "/Users/zhangyujun/Workspace/sign-cloud/dist/*" failed: No such file or directory (2)
rsync error: some files could not be transferred (code 23) at /SourceCache/rsync/rsync-42/rsync/main.c(992) [sender=2.6.9]

Warning: Task "rsync:test" failed. Use --force to continue.

Aborted due to warnings.

If I run the command under shell, there is no problem.

$ rsync dist/* rogerz@letsface:~/signature-cluster-dist --rsh "ssh -p 40022" --recursive

My configuration

    rsync: {
      test: {
        options: {
          src: 'dist/*',
          dest: '~/signature-cluster-dist',
          ssh: true,
          host: 'rogerz@letsface',
          port: '40022',
          recursive: true
        }
      }
    }

[jedrichards]

Huh ... I can't account for the command working on the command line but not in grunt-rsync. I'll look into that.

Meanwhile if you just want to indiscriminately copy the entire contents of your dist folder just the trailing slash should achieve that together with the recursive flag. Afaik the asterix is not needed. Something like this:

{
    src: 'dist/',
    recursive: true,
    //... other options
}

[rogerz]

Thanks. I found the hint of adding slash later on the README.md.

So the shell command is not interpreted by shell. It could be an issue in rsyncwrapper, right?

[jedrichards]

Yes that's pretty likely ... I'll see if I can reproduce it ..

[pepelsbey]

Just got the same error with *.zip wildcard, trying to rsync multiple ZIP archives without mentioning all of them:

options: {
    src: '*.zip',
    host: 'user@example.com',
    dest: 'example.com/temp/'
}

Error:

rsyncing ./*.zip >>> example.com/temp/

Shell command was: rsync ./*.zip user@example.com:example.com/temp/ --rsh ssh
ERROR
Error: rsync exited with code 23. rsync: link_stat "~/Desktop/./*.zip" failed: No such file or directory (2)
rsync error: some files could not be transferred (code 23) at /SourceCache/rsync/rsync-42/rsync/main.c(992) [sender=2.6.9]

The same command launched on its own works fine, as well as single archive.zip.

I'm just trying to recreate rsync --remove-source-files *.zip user@example.com:/temp/ command.

[jedrichards]

Confirmed. Looking into this ...

[jedrichards]

I'm drawing a blank on this so far. I'm investigating in the rsyncwrapper module btw, which grunt-rsync makes use of.

I wrote a failing test here:

https://github.com/jedrichards/rsyncwrapper/blob/master/tests/multi-copy.js#L86-L117

As far as I can tell the command string is being correctly built inside Node, but as soon as it hands off to the child rsync process the wildcard character gets stripped out. So ./*.txt becomes ./.txt.

I've tried replacing the asterix with the ASCII hex notation \x2A which doesn't help. I've tried surrounding the src string in single and double quotes, also doesn't help.

Someone else seems to be having similar issues:

http://stackoverflow.com/questions/11717281/wildcards-in-child-process-spawn

Any ideas?

[h4]

So, I try to explain... When you use rsyncwrapper, then you use child_process.spawn(). But spawn send arguments as string.

For example: child_process.spawn('ls', ['/tmp/*']) means $ ls "/tmp/*" in bash ant It is wrong command.

I think, you must to stop using rsyncwrapper and write some piece of code with child_process.exec(). Because with child_process.exec() you can use wildcards, see example in Node docs.

PS: @pepelsbey, can you translate my message to english?

[pepelsbey]

@h4, you did it clear enough :)

[jedrichards]

Ah OK, I see. The problem is we decided to move to using spawn because we wanted to show rsync stdout in realtime as it streamed in. But AFAIU if we switch to exec we have to buffer all the stdout and display it all at once ... which could be a problem for really long rsync transfers, no?

This was the issue where we discussed it: #15

Surely it must be somehow technically possible to pass the wildcard character through to a child process with spawn?

[jedrichards]

OK, I'm now using exec in rsyncwrapper and managing to retain the live stdout callback. Upgrade to grunt-rsync 0.3.0 and you should start to be able to use shell expanded wildcards properly in your src string. Let me know how you get on ...

jedrichards/rsyncwrapper@386a7ed