嘿，我帮你一步步拆解这个问题——核心原因是你用的是固定格式Fortran（.f后缀），而合作者的代码用了错误的续行符，后续的FILE错误也有几个常见排查方向，咱们慢慢说：

1. 先搞定续行符的问题（这是最直接的编译报错根源） #

固定格式Fortran的续行规则和咱们常见的自由格式（.f90）完全不一样，老代码的续行有严格要求：

• 代码行的第1-5列是标签区（一般留空就行），第6列是续行标记位——必须放一个非空格、非0的字符，比如*、1或者&（gfortran都认）
• 续行的内容得从第7列开始写

你原来的代码用了$当续行符，这根本不是固定格式的合法续行符，所以编译器才会报Bad continuation line这类错误。

给你两种正确的写法： #

第一种用传统的*当续行标记：

open( LUNIO, file='Myfile',
     *     status='replace' )

第二种用gfortran支持的&：

open( LUNIO, file='Myfile',
     &     status='replace' )

划重点：

• 第一行末尾不用加任何符号，直接换行就行
• 第二行的第6列必须是续行标记（*或&），后面再跟status='replace'的内容

要是嫌续行麻烦，把整个语句写成一行也可以，但要确保整个代码在固定格式的7-72列范围内（gfortran其实支持更长的行，但遵守标准更稳妥）：

open( LUNIO, file='Myfile', status='replace' )

2. 解决Invalid value for FILE specification的报错 #

当你把代码改成一行后还是报这个错，大概率是这几个原因：

（1）逻辑单元号LUNIO出问题了 #

• 先检查LUNIO是不是被正确定义成整数变量了，而且值得合法：
  • Fortran里1-6这些逻辑单元号一般是系统保留的（比如5是标准输入，6是标准输出），别用这些数
  • 最好用10以上的数，而且要确保这个单元号没被其他OPEN语句占用
• 如果LUNIO是个参数，看看定义对不对，比如应该是：

  integer, parameter :: LUNIO = 10
  

（2）文件名或路径的小坑 #

• Linux Mint是大小写敏感的，要是代码里写的是file='Myfile'，但实际文件是myfile或者MYFILE，虽然编译时不一定报错，但运行时会出问题——不过你这是编译报错，这个可能性相对低一些
• 文件名别带奇怪的特殊字符，要是有路径的话，Windows用\，Linux用/，或者用相对路径更稳妥

（3）试试宽松的编译选项 #

老代码可能当初是用Intel Fortran这类编译器编的，gfortran对语法的严格程度不一样。你可以试试加这两个编译选项：

gfortran -ffixed-form -ffixed-line-length-132 main.f -o main

• -ffixed-form明确告诉编译器这是固定格式代码（虽然.f后缀默认是，但显式指定更保险）
• -ffixed-line-length-132允许代码行最长到132列（默认是72列，老代码可能超出这个长度）

3. 额外排查：为什么去年能跑现在不行？ #

既然代码没改，那可能是环境变了：

• 编译器换了：比如原来用Intel Fortran，现在换成gfortran，两者对旧语法的兼容性有差异
• 文件编码或换行符变了：比如文件被转成了UTF-8带BOM，或者换行符从Windows的CRLF变成了Linux的LF（反过来也可能），这会让编译器解析出错。你可以用Notepad++这类编辑器把文件转成纯ASCII编码，换行符统一成对应系统的格式

内容的提问来源于stack exchange，提问作者Izzy