我可以使用什么正则表达式来修复这个非标准 Fortran 语法?
我有一堆使用非标准结构符号的 Fortran 77 文件 (此处描述):
STRUCTURE /item/
INTEGER id
CHARACTER(LEN=200) description
REAL price
END STRUCTURE
这显然是一些旧编译器使用的语法,但后来在 Fortran 90 中标准化为以下内容:
TYPE item
INTEGER id
CHARACTER(LEN=200) description
REAL price
END TYPE
我想做的是使用 sed
或其他一些适当的语法工具自动处理我的源文件以找到旧语法的所有使用并修补它们以使用更新的语法(即将“结构”的所有实例更改为“类型”并删除斜杠)。我确信我可以构建一些正则表达式来做到这一点,但我在这方面的技术还不够熟练,无法开始。
顺便说一句,与记录符号存在类似的不兼容性,也在链接中进行了描述:
RECORD /item/ pear, store_catalog(100)
成为:
TYPE(item) pear, store_catalog(100)
我假设也可以使用类似的技术来修复这些实例。
I have a bunch of Fortran 77 files that use a non-standard structure notation (described here):
STRUCTURE /item/
INTEGER id
CHARACTER(LEN=200) description
REAL price
END STRUCTURE
This is apparently a syntax that was used by some old compilers but was later standardized in Fortran 90 to the following:
TYPE item
INTEGER id
CHARACTER(LEN=200) description
REAL price
END TYPE
What I want to do is use sed
or some other appropriate tool to automatically process my source files to locate all uses of the old syntax and patch them to use the updated syntax (i.e. change all instances of "structure" to "type" and remove the slashes). I'm sure that I can build up some set of regular expressions to do this, but I'm not skilled enough in that art to get started.
On a side note, there is a similar incompatibility with record notation, also described in the link:
RECORD /item/ pear, store_catalog(100)
becomes:
TYPE(item) pear, store_catalog(100)
I assume similar techniques can be used to fix those instances also.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我对 Fortran 语法不太熟悉,所以我不知道如何概括这一点,但您的示例可以通过
注意使用
%
来分隔命令 (s,替代),模式和替换。通常您会使用
/
,但这是要匹配的模式的一部分。您的 RECORD 问题确实应该有类似的解决方案。
I'm not very familiar with Fortran syntax so I don't know how to generalize this, but your example can be tackled with
Note the use of
%
to separate the command (s
, substitute), pattern and replacement. Normally you would use/
, but that's part of the pattern to be matched.Your
RECORD
problem should indeed have a similar solution.