Windows API 与 UNIX shell(等效?) -- 或者 -- 编程语言何时是语言而不是脚本?

发布于 2024-07-26 08:12:36 字数 1460 浏览 7 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

野の 2024-08-02 08:12:36

抱歉,我不明白您似乎试图在 UNIX 和 Windows 之间做出区分。 作为使用和编程两者的人,对内核服务的调用是否在库中的区别似乎并不重要。 区别在于 - 调用是在编程上下文中进行的吗? 例如,我建议,有关 UNIX cat 命令的问题不属于这里,而有关 UNIX read() 系统调用(cat 必须在某种程度上使用)的问题则属于这里。

哦,内核和外壳之间没有“紧密集成”。

I'm sorry, I don't understand the distinction you appear to be trying to draw between UNIX and Windows. As someone who uses and programs both of them, the distinction about whether a call to a kernel service is in a library or not seems unimportant. The distinction is - is the call made in a programming context? For example, questions about the UNIX cat command do not, I suggest, belong here, whereas questions about the UNIX read() system call, which cat must use at some level, do.

Oh, and there is no "tight integration" between the kernel and the shell.

舟遥客 2024-08-02 08:12:36

将 UNIX 系统级别的讨论与编程放在同一领域是不公平的吗? strace/trus/par 是我用过的最有用的 UNIX 工具之一,它基于系统调用信息和报告,其他工具(如 ltrace)可以为库做类似的事情...

调试工具的讨论在 SO 上是完全有效的,国际海事组织。 我还没有看到调试工具问题已结束。

因此,如果您引用的已关闭问题是“如何找到哪些进程正在接触文件以调试我的程序”,那么我想它不会被关闭。 但它似乎是“我如何找到哪些进程正在接触文件以改善我卧室的氛围”,这与编程无关。

系统管理员问题属于其他地方。 Bash 编程与编程相关,而系统实用程序则不然。 这就像“如何将 Word 文档格式化为三栏”一样,与编程无关,但“如何编写 VB 脚本来格式化我的 Word 文档”则与编程相关。

Is it not fair to #include UNIX systems's level discussion in the same realm as programming? One of the most usefull UNIX tools I've ever used, strace/trus/par, is based around system call information and reporting, other tools like ltrace can do similar things for libararies...

Discussion of debugging tools is perfectly valid on SO, IMO. I've not seen a debugging tools question closed.

So if the closed question you reference had been 'how do I find what processes are touching files for debugging my program', then I imagine it wouldn't have been closed. But it appeared to be 'how do I find what processes are touching files to improve the ambience of my bedroom', which isn't programming related.

Sysadmin questions belong elsewhere. Bash programming is programming related, system utilities aren't. It's just the same as 'how do I make Word format my document in three columns' isn't programming related, but 'how do I program a VB script to format my Word document' is.

风渺 2024-08-02 08:12:36

我想如果您今天问同样的问题,它也会被关闭。 但它不是“与编程无关”,而是“属于服务器故障”。

如果您的问题是,我想跟踪我的程序接触的文件,即与开发工作特别相关的文件,那么它就无关紧要了。

I think if you asked the same question today it would also be closed. But rather than "not programming related", it would be "belongs on server fault".

If your question had been, I want to trace the files my program touches, i.e. specifcally related to development work, then it would be marginal.

魔法少女 2024-08-02 08:12:36

系统管理员,我同意不是为了这个
论坛,例如“如何让 qmail 做
X?”,而是“我的 smtp 病毒扫描程序是
基于 dnotify 的速度不够快?”
(回答)“嘿,使用inotify”,如此简单
歧视? 后者可以是
是 shell 或 linux 内核系统
来电。

我们不需要歧视。 如果有人正在编写一个 smtp 病毒扫描程序,那就是一个编程任务,而关于如何做到这一点的问题就是编程问题。 那么它是用 bash、汇编、C++ 或 Whitespace 编写的并不重要。

另一方面,问“我如何查看 Unix 上正在运行哪些进程?” 不是编程问题。 是的,答案是使用一个命令,该命令基本上是系统调用的包装器,那又如何? MS Word“保存文件”对话框也是写入文件系统调用的包装器。 这并不意味着它与编程相关。

我真的没有看到问题所在。

UNIX系统不就是这样吗
相关问题是编程
问题? 如果没有的话,哪里有
之间的边界
编程/脚本语言和
用户界面?

边界在这里:“问题是在编程环境中提出的吗?”
最终用户询问如何使用某些 Unix 命令不是编程问题。 但是程序员询问如何让他的程序在 Unix 上执行某些操作,则与编程相关。

没关系,shell命令和系统调用基本相同。 如果它是从编程上下文调用的,则它是与编程相关的。 否则就不是。 我们甚至可以在 Windows 上进行同样的区分。 如果我问“我应该如何从我的 Python 程序中调用 CreateFile”,那显然与编程相关。
但是“我正在运行的程序崩溃了,并给了我一条错误消息,说 CreateFile 失败。这是什么意思?” 与编程无关。

一个是从编程上下文中询问的,另一个只是恰好包含系统调用的名称。

如果您有疑问,请参阅维基百科对“编程”的定义:

计算机编程(通常缩写为
编程或编码)是
编写、测试的过程,
调试/故障排除,以及
维护源代码
计算机程序

这对我来说似乎很清楚。 您正在阅读/编写源代码吗? 如果没有,那就很难编程了。 成为通过编程创建的实用程序的用户就足够了。

System admin, I agree is not for this
forum, like "How to I make qmail do
X?", but is "My smtp virus scanner is
not fast enough, based on dnotify?"
(answer) "Hey, use inotify", so easy
to discreminate? The latter may either
be shell or linux kernel system
call's.

We don't need to discriminate. If someone is writing a smtp virus scanner, that is a programming task, and questions about how to do it are programming questions. Then it doesn't matter if it is written in bash, assembly or C++ or Whitespace.

On the other hand, asking "how do I see which processes are running on Unix?" is not a programming question. Yes, the answer will be to use a command which is basically a wrapper around a system call, and so what? The MS Word "save file" dialog is a wrapper around a write file system call too. That doesn't make it programming-related.

I don't really see the problem.

Is it not the case that UNIX systems
related questions are programming
questions? If not, where is the
boundry between a
programming/scripting language and
user interface?

The boundary is here: "Is the question made in a programming context?"
A end-user asking how to use some Unix command is not a programming question. But a programmer asking how to make his program do something on Unix, is programming-related.

It doesn't matter that the shell command and the system call are basically identical. If it is invoked from a programming context, it is programming-related. Otherwise it is not. We can even make the same distinction on Windows. If I ask "How should I call CreateFile from my Python program", that is clearly programming-related.
But "The program I was running crashed, and gave me an error message saying CreateFile failed. What does that mean?" is not programming-related.

One is asked from a programming context, the other simply happens to include the name of a system call.

If you're in doubt, here's Wikipedia's definition of "programming":

Computer programming (often shortened
to programming or coding) is the
process of writing, testing,
debugging/troubleshooting, and
maintaining the source code of
computer programs

That seems pretty clear to me. Are you reading/writing source code? If not, it's hardly programming. Being the user of a utility that was created through programming is enough.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文