search for: argstring

...OSSIM_SDK_DIR}) >> >> where IOSSIM_SDK_DIR is the path including spaces and parens. > > It looks like the _CFLAGS values are used in the module > cmake/Modules/CompilerRTUtils.cmake: > > function(set_target_compile_flags target) > foreach(arg ${ARGN}) > set(argstring "${argstring} ${arg}") > endforeach() > set_property(TARGET ${target} PROPERTY COMPILE_FLAGS "${argstring}") > endfunction() > > but that makes no attempt to escape or quote anything. > > The COMPILE_FLAGS target property was a very early CMake feature...

Dear R-help, Can some one tell me how to do the following (if it's possible)? Suppose I have a function like this: f <- function(x, y, ...) { ## some code g(x, y, ...) ## some more code } The problem is that g() may not understand everything that comes through in "...". Is there a way to delete some component of "..." and then pass it to g()? Here's

Commit-ID: 527bee886ced0d22428417d60a638521e435bb96 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=527bee886ced0d22428417d60a638521e435bb96 Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Wed, 30 May 2018 02:06:03 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:55 +0000 [klibc] dash: expand: Do not

Commit-ID: 4bfffb1572c9d1b77538b5a3e92c27f91bd2ee99 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=4bfffb1572c9d1b77538b5a3e92c27f91bd2ee99 Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Mon, 25 Feb 2019 14:00:31 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:55 +0000 [klibc] dash: expand: Fix

In the past, I had restricted rsync so that the -e option was disallowed. As of rsync-3.0.0, I'm now seeing the following requests being made (on the server side): rsync --server -vlogDtprze.iL . I want to prevent '-e' as a client side option so arbitrary programs can't be executed. I found the following, but didn't trace through to verify exactly where I was in the code

It seems latest rsync pass -e to the remote server to specify rsync client is a preversion (A thing I understand because -e works on all rsync version). However, this cause problems on server having options restriction, like denying -e because it allow to execute any command on it. So I suggest this patch to limit effect to unstable version of clients. WDYT ? Regards. Index: options.c

Hi, I recently encountered a problem with array subsetting and came up with a fix. Given an array of arbitrary dimensions, in which the number of dimensions is only known at runtime, I wanted to extract a subarray. The main issue with doing this is that in order to extract a subarray from an array of (say) 4 dimensions you usually specify something like this a.subarray <- a[,c(4,2),1:5,]

A couple of llvm sub-projects have been failing to build for me for a while (compiler-rt asan and util/unittests, at least). It turns out to be due to the fact that some paths on my system include spaces and other special characters, but the the build.ninja file was not generated with correctly quoted strings. Specifically I'm on OS X and the command is setting -isysroot to a location inside

...arget, which looks fine to me: -- {CAN_TARGET_x86_64}: TRUE -- {CMAKE_BINARY_DIR}: /home/mohit/compiler-rt_build -- {SIMPLE_SOURCE}: /home/mohit/compiler-rt_build/CMakeFiles/simple.cc -- {TARGET_x86_64_CFLAGS}: -m64 -- TARGET_{arch}_OUTPUT: TARGET_x86_64_OUTPUT -- -DCMAKE_EXE_LINKER_FLAGS:STRING={argstring}:-DCMAKE_EXE_LINKER_FLAGS:STRING= -m64 -- {CAN_TARGET_i386}: FALSE -- {CMAKE_BINARY_DIR}: /home/mohit/compiler-rt_build -- {SIMPLE_SOURCE}: /home/mohit/compiler-rt_build/CMakeFiles/simple.cc -- {TARGET_i386_CFLAGS}: -m32 -- TARGET_{arch}_OUTPUT: TARGET_i386_OUTPUT -- -DCMAKE_EXE_LINKER_FLAGS:STR...

In debian bug #493559 (http://bugs.debian.org/493559) the problem is that when requesting a file from an older version rsync, the remote server gives an error: $ rsync rsync://rsync.blackholes.us/zones/countries/countries.rbl /tmp rsync: on remote machine: -: unknown option rsync error: requested action not supported (code 4) at clientserver.c(517) rsync: connection unexpectedly closed (4 bytes

Hi, When using the latest rsync 3.1.0 client, connecting to a pre 3.1.0 (i.e. 3.0.9 and earlier, protocol version 30) server running in daemon mode and requesting a recursive (incremental by default) file transfer, the variable use_safe_inc_flist is not set (affecting how I/O errors are handled during file list generation). so it is set for: 3.0.9 client -> 3.0.9 daemon 3.0.9 client ->

hi. return value of close() (receiver.c) is ignored. when running out of quota on NFS (for example), this can happen (without the patch): output file(s) is/are truncated to 0 bytes and rsync reports success. with the fix, this happens: close "/home/luser/.test.mp3.PwaG50": Disc quota exceeded rsync error: error in file IO (code 11) at receiver.c(464) ... ...and additionally, test.mp3

We use rsync to update an nfs server. After an update, we noticed that a large number of clients didn't see the updated data. It took me a while to be able to reliably reproduce this problem, but it happens on old and new versions of rysnc. It also happens across all the platforms we use here (sun/linux/netapp). This shows the problem: [Note my home directory is NFS mounted]

People of cygwin & rsync, I recently attempted to get cygwin and rsync working to solve a backup/mirroring need in my computer life. Well, as you might guess, I ran into a little but of trouble. Strangely enough, rsync seemed to be regularly hanging when I attempted to do a "get" (sycronize a remote to a local dir). Well, considering I want to automate this, that was not going

> Just curious: what about the rsync+ patch? Thanks for the reminder. I've just committed Jos's rsync+ patch onto the "branch_mbp_rsyncplus_merge" branch. If it works OK and nobody screams I will move it across onto the main tree tomorrow or Wednesday. I see the patch doesn't add documentation about the new options to the man page, so we should fix that in the future.

Synopsis: Prior to the 2.6.4pre versions, issuing 'rsync rsync://host/module/' behaved effectively as 'ls -l'. I've toyed with various options in an attempt to get an 'ls -l' style output, but to no avail. As I have a small handful of scripts that rely on this no-longer-functioning functionality, this could be considered a Bad Thing(TM). Following is an example of

I was trying to use rsync to send files to a fileserver using an rssh restricted server. It refuses, saying that trying to override the shell with -e is forbidden. I didn't type "-e". When I look at the source, I see /* Checking the pre-negotiated value allows --protocol=29 override. */ if (protocol_version >= 30) { /* We make use of the -e

Commit-ID: 1285f79afbd9686c78c7815203ecbf3e87a81ff8 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=1285f79afbd9686c78c7815203ecbf3e87a81ff8 Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Wed, 12 Sep 2018 14:27:16 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:55 +0000 [klibc] dash: expand: Fix

I just took a look at the 2.5.5 codebase to see how easy it would be to write a little driver script that downloads a big directory tree from an rsync daemon the chunky way (get a list of a module's subdirectories and do the transfer by subdirectory). The reason for doing this is obvious when you have large directory trees, as is the case for many of us. Unfortunately the way list_only is

...ile loading shared libraries: libclangFrontend.so.7: cannot open shared object file: No such file or directory [root at localhost ~]# /usr/share/bcc/tools/opensnoop Traceback (most recent call last): File "/usr/share/bcc/tools/opensnoop", line 19, in <module> from bcc import ArgString, BPF File "/usr/lib/python3.6/site-packages/bcc/__init__.py", line 27, in <module> from .libbcc import lib, bcc_symbol, bcc_symbol_option, _SYM_CB_TYPE File "/usr/lib/python3.6/site-packages/bcc/libbcc.py", line 17, in <module> lib = ct.CDLL("libbcc....