now I get a bizarre error as if I have changed/lost a closing argument such as fi, statement closure such as , or a hidden series of tabs.
This is the message I get in my err file:
./cron_run.sh: line 156: syntax error near unexpected token `else'
./cron_run.sh: line 156: ` else'
Again, I did not touch these lines. Not even close and what I added was another operation to dump a mongo collection to the backup directory. So I had:
...start of script
mongodump... # this was existing
mongodump... # this was the addition
...rest of script (about 70) lines unchanged
Key point:
the above lines worked
the code/server executed as expected
the error/crash occurred at the end of the process after execution (so the whole thing actually worked!)
I looked at the code with syntax highlighting (vim, nano) and I cannot see anything wrong with it (at least not an obvious thing such as a bracket, fi or missing back tick)!
Any suggestions?
I'm getting this error when trying to [compass compile]:
Syntax error: Mixin columns takes 1 argument but 2 were passed.
Everybody else on my team do not get this error. The offending line of code is:
#include columns(9,9);
Please assist.
Ok, what fixed this problem is installing the [compass-susy-plugin] gem.
I am trying to use ren-regexp to replace a character in filenames like so:
./ren-regexp.pl "s/_/-/g" *.jpg
Which I think should replace _ with - in filenames that are jpgs, but what I get is:
./ren-regexp.pl: line 4: syntax error near unexpected token `newline'
./ren-regexp.pl: line 4: `<!DOCTYPE html>'
I also tried
perl ren-regexp.pl "s/_/-/g" *.jpg
Which resulted in lots of errors such as:
Bareword found where operator expected at ren-regexp.pl line 252, near "time class"
(Do you need to predeclare time?)
Bareword found where operator expected at ren-regexp.pl line 252, near ""js-relative-date" datetime"
(Missing operator before datetime?)
Bareword found where operator expected at ren-regexp.pl line 252, near ""2011-04-13T16:40:41-07:00" title"
(Missing operator before title?)
Number found where operator expected at ren-regexp.pl line 252, near "April 13"
(Do you need to predeclare April?)
Bareword found where operator expected at ren-regexp.pl line 262, near ""/msabramo/ren-regexp/tree/17026c762c41e2b88ed91bf78b63e54859b706e5" class"
(Missing operator before class?)
I tried using the examples shown on the GitHub page as well as here:
Mass replace characters in filenames from terminal?
Where am I going wrong? Running just 'perl ren-regexp.pl' by itself also results in the above set of errors.
It looks like you downloaded the script from
https://github.com/msabramo/ren-regexp/blob/master/ren-regexp.pl
instead of
https://raw.github.com/msabramo/ren-regexp/master/ren-regexp.pl
The former link will actually give you an HTML document that is unsuitable for passing into perl.
Or you could view the first link in a browser, and then copy and paste the Perl code to a file (and strip the line numbers).
I am trying to get this Ruby inline C code http://pastie.org/2825882 to work. The code works in vanilla C, but here I get errors and warnings. What causes this error?
./backtrack_inline.rb:67: error: lvalue required as unary '&' operand
Also, why do I get the following error?
./backtrack_inline.rb:73: error: too few arguments to function 'backtrack'
Inspecting the resulting C code ( http://pastie.org/2826036) I fail to see anything wrong with the arguments. But I do also get the following warnings:
./backtrack_inline.rb:73: warning: passing argument 1 of 'backtrack' makes integer from pointer without a cast
./backtrack_inline.rb:73: warning: passing argument 2 of 'backtrack' makes integer from pointer without a cast
./backtrack_inline.rb:73: warning: passing argument 3 of 'backtrack' makes integer from pointer without a cast
Starting with this:
./backtrack_inline.rb:73: error: too few arguments to function 'backtrack'
If you look at your generated code, the backtrack function is defined on line 29:
static VALUE backtrack(VALUE self, VALUE _ss, VALUE _s, VALUE _p, VALUE _mm, VALUE _ins, VALUE _del) { ... }
It has seven arguments, the original six, plus VALUE self as it has been converted into a method on the Scan class.
The call to this function, on line 67 looks like this:
end = backtrack(ss, s, p, mm, ins, del);
It has only six arguments. RubyInline doesn't convert this to a call to a method on the object, it simply copies it verbatim. This is also where the warnings about makes integer from pointer without a cast come from: the function definition has been converted to take VALUEs, but you're calling with the original types.
The error message says that the error is from line 73 in backtrack_inline.rb because of the directive on line 54 of the generated code:
# line 61 "./backtrack_inline.rb"
which basically tells the compiler to "reset" its line and file values for errors, and treat the next line (55) as being line 61 in the file ./backtrack_inline.rb. The actual line is 67, 12 ahead of 55, but the compiler reports it as being 73, 12 ahead of 61 (the value it was reset to) and from a differnt file. This technique doesn't really work in this case as it doesn't take into account the extra lines added by RubyInline. The actual line in the source is 69.
A simple fix for this is to change the definition of the backtrack function to be just a C function rather than add it as a method on the object. Change builder.c to builder.prefix (on line 38 of your Ruby file). This won't work if you want to have backtrack available as a method on the object in Ruby. If that's the case you might need create another function to be the method, which then wraps the "real" backtrack function.
Next, looking at
./backtrack_inline.rb:67: error: lvalue required as unary '&' operand
This actually refers to line 61 of the generated code, which looks like:
char* s = StringValuePtr(rb_iv_get(self, "#seq"));
StringValuePtr is a macro which is defined as:
#define StringValue(v) rb_string_value(&(v))
This is where the & in lvalue required as unary '&' operand comes from. You need to add a local variable to be the lvalue:
VALUE seq = rb_iv_get(self, "#seq");
char* s = StringValuePtr(seq);
In my case (Mac OS X Snow Leopard, Ruby 1.9.3-p0, RubyInline 3.11.0) these two changes made the script run without errors, but gave the warning:
backtrack_inline.rb:47: warning: implicit conversion shortens 64-bit value into a 32-bit value
This actually refers to line 46 of the ruby file:
return (s - ss) - 1;
s and ss are char *, i.e. 64 bit pointers (on this machine), and the return type of the function is int - 32 bits. Adding an explicit cast fixed this:
return (int)((s - ss) - 1);
It now runs cleanly:
ruby-inline $ ruby backtrack_inline.rb
14
ruby-inline $
(I hope 14 is the correct answer!)
Here's a version of the script with these changes.
OK, the question was also answered at Ruby Forum:
http://www.ruby-forum.com/topic/2959614
Ok... thought a bit more about this.
you are calling a variable end. While this isn't a reserved word in C - and ruby shouldn't be looking at it... perhaps ruby is getting confused?
I'd suggest you have a go at renaming it just in case. Worthwhile trying even just to rule it out.
Say, I have two adjacent functions subfunc() and main() in the Mach-O executable and want to disassemble all instructions from subfunc() to main()+0x10.
I know I can cast functions to addresses using `(void(*)())subfunc` - isn't there an easier way?
My attempt is as follows, but I get the error message below:
dis -s `(void(*)())subfunc` -e `(void(*)())main+0x10`
error: error: arithmetic on a pointer to the function type 'void ()'
How can I fix this?
This appears to be the correct syntax:
dis --start-address `(void(*)())main` --end-address `(void(*)())main`+0x10
The very small difference between this syntax and the variant you tried is that the +0x10 offset goes outside the backtick characters, i.e. the offset goes after the closing backtick.
FWIW this variant also appears to work correctly:
dis --start-address `(void(*)())main` --end-address 0x10+`(void(*)())main`
Discovery process:
I was unfamiliar with the "backtick" + function cast that you described in your original question so that was a very helpful starting point.
In my case I was trying to set a breakpoint at a function offset inside a shared library and got about as far as this before my search landed me on your question:
breakpoint set --shlib libexample.dylib --address `((void*)some_function)+81`
error: error: function 'some_function' with unknown type must be given a function type
error: 1 errors parsing expression
The use of your function cast hint met the "function type" requirement stated in the error message so I was next able to get to:
print (void(*)())some_function
(void (*)()) $38 = 0x00000001230094d0 (libexample.dylib`some_function)
I then tried the backtick variant which appeared to work but I wanted the value to be displayed in hexadecimal:
print `(void(*)())some_function`
(long) $2 = 4882207952
But when I tried to use the -f hex format option with print I got an error:
print -f hex `(void(*)())some_function`
error: use of undeclared identifier 'f'
error: 1 errors parsing expression
Eventually I noticed the comment 'print' is an abbreviation for 'expression --' at the bottom of the help print output and realised that means it's (apparently?) not possible to use an alternative display format with print because it gets converted into expression -- -f hex ... which is not valid syntax.
Eventually I figured out the required placement & combination of command name, display format and "--" to make it display as desired:
expression -f hex -- `(void(*)())some_function`
(long) $7 = 0x00000001230094d0
For no particular reason (that I can remember) it was at this point I tried placing the offset outside the backticks and it worked!
expression -f hex -- `(void(*)())some_function`+81
(long) $12 = 0x0000000123009521
And it still worked when I tried it with a breakpoint:
breakpoint set --shlib libexample.dylib --address `(void(*)())some_function`+81
Breakpoint 6: where = libexample.dylib`some_function + 81, address = 0x0000000123009521
Then I verified that it also worked with the dis command from your original question:
dis --start-address `(void(*)())some_function` --end-address `(void(*)())some_function`+81
And confirmed that the bare function name was not sufficient:
dis --start-address some_function --end-address `(void(*)())some_function`+81
error: address expression "some_function" evaluation failed
I also re-confirmed that the offset being between the backticks did not work:
dis --start-address `(void(*)())some_function` --end-address `(void(*)())some_function+1`
error: error: arithmetic on a pointer to the function type 'void ()'
error: 1 errors parsing expression
It was at this point that I realised I was able to parse the error message (as it was presumably intended):
[arithmetic on a pointer] [to the function type] ['void ()']
The underlying issue being "arithmetic on a pointer"...
Which further research shows is both "undefined on pointers to function types" and available as a gcc extension:
https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html
Why is it not allowed to perform arithmetic operations on function pointers?
Should clang and gcc produce a diagnostic message when a program does pointer arithmetic on a function pointer?
Incrementing function pointers
Function pointer arithmetic
How to print the address of a function?
https://github.com/llvm/llvm-project/blob/f804bd586ee58199db4cfb2da8e9ef067425900b/clang/test/Sema/pointer-addition.c
https://reviews.llvm.org/D37042
Which brings us back to the comments by #JasonMolenda & #JimIngham and how the function pointer arithmetic parsing is special-cased.
To my mind the "error: arithmetic on a pointer to the function type..." message you received is at best poor UX & at worst a bug--given that lldb itself essentially displays address references in that manner:
0x1230094f9: jle 0x123009cc2 ; some_function + 2034
I feel similarly about libexample.dylib`some_function + 81 being displayed but AFAICT not being parsed.
In conclusion, this form works:
`(void(*)())some_function`+0x10
Now I just need to figure out why some_function isn't doing what I think it should... :)