invalid character name at (1) - compilation

I am trying to compile a fortran code. It will analyze an X file in an Y directory and then create a new file Z with the results. But there is something wrong occurring.
When I write the directory I see that it is too much for one line and then I try to continue it in the next one doing this:
namech='/home/matheus/Documents/UFABC/IC/Spectra/Elliptical/'
+ 'espec.fits'
But, when I try to compile using the command
gfortran Codigo.f -o TESTE -Lcfitsio -lcfitsio
I get this error message:
+ 'espec.fits'
1
Error: Invalid character in name at (1)
Can someone help me? Actually I do not know what this error is. The directory is 100% right. And when I move the archives to a simpler directory to be able to write everything in one line, it works! So is there something wrong with the "+"?
Thank you.
Edit1
Actually, when I add "&" in the end of the line, it gives me this error message:
namech='/home/matheus/Documents/UFABC/IC/Spectra/Elliptical/'&
1
Error: Unclassifiable statement at (1)
Codigo.f:60.7:
+ 'espec.fits'
1
Error: Invalid character in name at (1)
And with "//":
namech='/home/matheus/Documents/UFABC/IC/Spectra/Elliptical/'//
1
Error: Syntax error in expression at (1)
Codigo.f:60.7:
+ 'espec.fits'
1
Error: Invalid character in name at (1)
Edit2
Thank you so much for helping me. Well, I solved the problem switching to the ".f90" form.
Just one more question: do you know why it does not recognize the "c" for comments in the code? Thank you again! :)

This part of your compilation statement:
gfortran Codigo.f
will treat the source file, with its .f suffix, as fixed form source. This means that a continuation line is indicated by any character (other than a blank or a 0) in column 6.
However, the error message you get suggests that the + in the second line of your snippet is not in column 6 and that the compiler is treating it as the initial character in a new entity name for which it is not valid. The fact that the + is aligned, vertically, with n in the previous line strengthens my suspicion that this may the root of your problem.
Adding the ampersand, as suggested in a now-deleted answer, doesn't actually help in this case if you continue to tell the compiler that it is dealing with a fixed form source file. & is only used for continuation in free form source files. Adding the string-concatenation operator, //, doesn't help either since it is not followed by another string but a line ending. //& would help but is probably unnecessary.
I think you have 2 possible solutions, but choose only one:
Stick with fixed form and get the alignment right.
Change the file suffix to .f90 which will cause gfortran to treat the source file as free-form.
If you go for option 2 (which I would recommend) you can then either use & at the end of the continued line or you could simply merge the lines. In free-form the maximum line length is 132 characters.

Adding to High Performance Mark's answer:
If you continue with FORTRAN 77, most compilers have an option to increase the allowed line length, e.g., -ffixed-form -ffixed-line-length-none for gfortran. As already stated, Fortran >=90 has line length of 132, so you wouldn't need to split the line.
Finally, if you want to split the line in Fortran >=90, you need two ampersands. In most cases you need one, but to split a string you need two:
namech='/home/matheus/Documents/UFABC/IC/Spectra/Elliptical/&
&espec.fits'

Related

How to handle improper Data Coming from CSV in Informatica

I have source file (CSV) and need to load into target (Oracle). But I got an error
FR_3065 ROW[4],Filed [Student_rollnumber]:Invalid Number:[.].The row will be skipped
CSV TABL
Student_rollnumber,Studnet_Name,Marks,Subjects
10,'Revanth',70,"Maths",
11,'Satish',85,Science
12,'Anil',75,"Java
",
13,'Surya',90,"C++",
14,'Ramana',85,"python",
15,'Sudheer'70,"Informatica
",
16,'Prakash',85,"SQL"
I found that in line number 4 the qouts and comma(",) are in the next line how to concat that both ("Java",) And make it single column(Subject)
MatchQuotesPastEndOfLine mentioned by Koushik should work.
Alternatively you may use sed with below pattern to replace newline+" with simply just a " - as a result removing the new line at the end of quoted string.
sed ':a;N;$!ba;s/\n"/"/g'
Feel free to test this gist.
This however will remove just the ending new line and will not help if it's anywhere in the middle. As said, the MatchQuotesPastEndOfLine mentioned by Koushik is the best possible solution.
Above has been based on this question.

Go compiler: error line number is incorrect giving 1048575 i.e. 0xFFFFF when problem is further on in the file

I am testing code-generation functionality and deliberately creating very large .go source files.
However I see errors with go compiler at line 1048575 (which is 0xFFFFF) such as:
generated.go:1048575:75: invalid character U+0040 '#'
generated.go:1048575:76: const declaration cannot have type without expression
generated.go:1048575:88: syntax error: unexpected E_Blah_Blah, expecting semicolon or newline or )
Is this a known limitation?
EDIT-1: Commenters asked for more info on content of generated file; further tests show when I deliberately introduce a new error at line 1048573 or 1048574 it gets reported as I'd expect, but if I introduced one at 1048575 or higher line number the file I always get the error reported at 1048575.
EDIT-2: I realise now the original issue invalid character U+0040 '#' was indeed a bug in my generated file but it was further down that line number the compiler tells me.
EDIT-3: So I guess the question should really have been:
is there a way to have the go-compiler give the correct line number for a problem if error further down than line 0xFFFFF?
Is this a known limitation ?
No.
The root cause was:
https://github.com/golang/go/issues/36850
i.e. Compiler bug: error line number is capped at 0xFFFFF
as per comment from #icza

Building libssh project - target pattern contains no '%'

I'm trying to install libssh-0.8.5 onto Ubuntu 16.04 using the instructions from the install.readme provided. I follow every step as stated, but I get an error after executing the make command to build the project. The error is as follows:
[ 65%] Built target exec
tests/CMakeFiles/ssh_ping.dir/flags.make:8: *** target pattern contains no '%'. Stop.
CMakeFiles/Makefile2:1696: recipe for target 'tests/CMakeFiles/ssh_ping.dir/all' failed
make[1 ]: *** [tests/CMakeFiles/ssh_ping.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2
I have researched and seen that it could be a syntax error somewhere in my make file that is preventing the build to continue. I have looked at the target make file giving the problem, but cant seem to identify what is causing the error.
The flag.make file is as follows:
The problem seems to be coming from the highlighted bold line. Can anyone see what I am missing?
On StackOverflow (and most other similar sites), please cut and paste text into your questions and format them using the proper markdown facilities, rather than attaching images containing text. The latter is difficult to read and we can't cut and paste it into our answer to show where things are going wrong.
You cannot embed newlines in quoted strings, in makefiles. Make is completely line-oriented and does not parse quotes at all. So to make this:
FOO = "bar
biz"
is not considered one line assigning a value containing a newline to a variable FOO. Instead, it's considered two lines, the first of which is assigning the value "bar to variable FOO and the second of which is a syntax error since make can't parse the string baz" as a valid command.
Apparently ssh wasn't installed properly on your platform, while cmake relies on it. I am a bit surprised that cmake itself did not raise an error when generating flag.make but as I don't use cmake I do not know whether it is its normal behaviour or not.
Anyway, when cmake tried to detect your version of OpenSSH it did it by running ssh and got an error message instead of the version number it wanted. This error message got inserted in the generated flag.make Makefile. Because the second line of this error message (I could copy-paste it here if it was not in a picture in your question) has the:
a: b: c
form, make tried to interpret it as a static pattern rule but as it contains no % wildcard character, make raised a syntax error.
What happens if you try to run /usr/bin/ssh -V on the command line?

Lines added to output text file

I am compiling a Fortran 77 project with Visual Studio 2008 using Intel Fortran 2013 and I am having a stupid issue in one of the output file created by the executable.
In this file, I am expect to read something like
EXPECT FILE :
"
foo1
foo2
"
instead, I obtained almost the same but with empty lines lines in between:
OBTAINED FILE:
"
foo1
foo2
"
This can seem like a detail but it is actually a problem as this file is read by another program which is not checking for the empty lines.
The strange thing is that I also compiled this under Linux and the problem does not appear, that's why I concluded it is necessarily a Visual Studio option issue.
The source code looks like this :
character*80 comment(2)
comment(1)="foo1"
comment(2)="foo2"
do i=1, 2
write(10,*)comment(i)
end do
I tried to change several options inside the Fortran Properties but none of them did work
Anyone having some idea about this ?
This is (most likely) because the string is printed including all 80 characters, i.e., even with the trailing spaces (as suggested in the comments). One can observe this directly by putting the string being printed in quotes:
WRITE(10, '(A)') "'"//comment(i)//"'"
One solution would be to use, e.g.,
WRITE(10, '(A)') TRIM(ADJUSTL(comment(i)))
Here, ADJUSTL would remove also leading spaces. If this is not desirable, one could use just TRIM.

Error: Invalid character in name at (1)

I am trying to compile a fortran file along with some .h files in FORTRAN. The .h files contain definition for common blocks of variable. When I compile them in Fortran, I get the following error:
integer knue,ke,knumu,kmu,knutau,ktau,ku,kd,kc,ks,kt,kb,kgamma,
1
Error: Invalid character in name at (1)
The code where this error occurs is,
Now my question is, does this "1" point where the error is?
The lines of code which this errors points is,
integer knue,ke,knumu,kmu,knutau,ktau,ku,kd,kc,ks,kt,kb,kgamma,
& kw,kz,kgluon,kh1,kh2,kh3,khc,ksnue,kse1,kse2,ksnumu,ksmu1,
& ksmu2,ksnutau,kstau1,kstau2,ksu1,ksu2,ksd1,ksd2,ksc1,ksc2,
& kss1,kss2,kst1,kst2,ksb1,ksb2,kn1,kn2,kn3,kn4,kcha1,kcha2,
& kgluin,kgold0,kgoldc
Also, is there something wrong with the way continuation are used. I am using gfortran to compile this file.
It looks like you are using Fortran 77 style line continuations and trying to compile with Fortran 90 style free format code. You either need to compile using the gfortran -ffixed-form option, or format the code using Fortran 90 style line continuations:
integer knue,ke,knumu,kmu,knutau,ktau,ku,kd,kc,ks,kt,kb,kgamma, &
kw,kz,kgluon,kh1,kh2,kh3,khc,ksnue,kse1,kse2,ksnumu,ksmu1, &
ksmu2,ksnutau,kstau1,kstau2,ksu1,ksu2,ksd1,ksd2,ksc1,ksc2, &
kss1,kss2,kst1,kst2,ksb1,ksb2,kn1,kn2,kn3,kn4,kcha1,kcha2, &
kgluin,kgold0,kgoldc
I had this problem when modifying scipy and trying to compile it. The following identation was necessary to make it work, with the star * at column 5. It works for both Fortran 77 and 90 styles.
double precision a,abseps,abserr,alist,area,area1,area12,area2,
* a1,a2,b,blist,b1,b2,correc,dabs,defabs,defab1,defab2,d1mach,
* dmax1,dres,elist,epmach,epsabs,epsrel,erlarg,erlast,errbnd,
* errmax,error1,error2,erro12,errsum,ertest,f,oflow,resabs,
* reseps,result,res3la,rlist,rlist2,small,uflow,areav
To your first question, yes the "1" normally denotes the point in the code where the error occurs. The code as such looks ok otherwise.
Actually the Fortran 77 continuation column is number six.
http://web.stanford.edu/class/me200c/tutorial_77/03_basics.html

Resources