0

I've seen a number of question's closed as "Not programming related" (e.g. https://stackoverflow.com/questions/397854/what-process-accesses-my-hdd)

I understand that their's several alternative site (stackoverflow) themed-forums and to attempt keep site question's to a minimum also some may argue that this is too subjective, o well, I got madly flamed for my first answer, so here's my first question, I'll try to frame it in a psudo-contextual-basis (jepordy style) to keep some regulator's at bay...

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...

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.

I am not much of one for standards (read one too many lately), I'm adding a tag on POSIX "command language", to shift some focus on idenitfying some definative info.

Systems level interaction being somewhat of a programming-interface(API)/user-interface(shell) duality (perticularly for UNIX).

If the context of an inquisitor be primarially interface based and it is an easy quarry (or even typical) to solution an exclusivly programming/API responce, to help man and machiene alike, why require a domain change (body of knowledge or URL domain;)?

4

4 回答 4

2

对不起，我不明白您似乎试图在 UNIX 和 Windows 之间进行区分。作为同时使用和编程它们的人，对内核服务的调用是否在库中的区别似乎并不重要。区别是 - 调用是在编程上下文中进行的吗？例如，我建议，关于 UNIX cat 命令的问题不属于这里，而关于 UNIX read() 系统调用（cat 必须在某个级别使用）的问题则属于这里。

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

于 2009-07-05T09:33:03.047 回答
2

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

调试工具的讨论在 SO，IMO 上是完全有效的。我还没有看到调试工具问题关闭。

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

系统管理员问题属于别处。Bash 编程是与编程相关的，而系统实用程序则不是。这就像“如何使 Word 将我的文档格式化为三列”与编程无关，但“如何编写 VB 脚本来格式化我的 Word 文档”是一样的。

于 2009-07-05T09:50:37.647 回答
0

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

如果您的问题是，我想跟踪我的程序接触到的文件，即与开发工作特别相关的文件，那么这将是微不足道的。

于 2009-07-05T10:42:38.210 回答
0

系统管理员，我同意不是针对这个论坛的，比如“我如何让 qmail 做 X？”，而是“我的 smtp 病毒扫描程序不够快，基于 dnotify？” （回答）“哎，用inotify”，这么容易辨别？后者可能是 shell 或 linux 内核系统调用。

我们不需要歧视。如果有人正在编写 smtp 病毒扫描程序，那是一项编程任务，而关于如何去做的问题则是编程问题。那么它是用 bash、汇编、C++ 还是 Whitespace 编写的都没有关系。

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

我真的没有看到问题。

UNIX系统相关的问题不是编程问题吗？如果不是，那么编程/脚本语言和用户界面之间的界限在哪里？

边界就在这里：“这个问题是在编程环境中提出的吗？” 最终用户询问如何使用某些 Unix 命令不是编程问题。但是一个程序员问如何让他的程序在 Unix 上做某事，这与编程有关。

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

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

如果你有疑问，这里是维基百科对“编程”的定义：

计算机编程（通常简称为编程或编码）是编写、测试、调试/故障排除和维护计算机程序源代码的过程

这对我来说似乎很清楚。你在读/写源代码吗？如果没有，它几乎不是编程。成为通过编程创建的实用程序的用户就足够了。

于 2009-07-05T11:23:15.133 回答