J
Jorgen Grahn
Depends on if 'filename', in the actual application, can be based on
user input. Of course, if you use remove() or something, you don't
have to worry about that.
/Jorgen
Depends on if 'filename', in the actual application, can be based on
user input. Of course, if you use remove() or something, you don't
have to worry about that.
/Jorgen
J
Jorgen Grahn
He didn't say it's incorrect. If he's like me, he's all for
half-baked code and avoiding effort -- up to a point.
Depends. If all he wants is an unordered list of file names, learning
the API may well be easier than popen()ing ls.
/Jorgen
C
Chicken McNuggets
That is correct. I asked the question. I didn't mean this thread to turn
into a flame fest though so apologies for asking a question that was
off-topic to this list.
Frankly though I think people could just relax a little. It is not the
end of the world if someone asks a question that is off-topic. A simple
"You'll get a better answer on comp.unix.programmer" would have been
sufficient.
J
James Kuyper
How?
It had two main parts. The first part pointed out to the OP the clues
that he should have used to realize that some other forum would be a
more appropriate one for his question. The second part identified c.u.p
as that more appropriate forum. Would you have left out the first part?
It seems to me that it's important for people to understand how easy it
is to determine that c.u.p is a more appropriate forum than this one for
questions like this one.
C
Chicken McNuggets
Because the "ls" command was an example. I really want to process the
output of things like "iostat", "/proc/loadavg", "sar" and "tcpdump".
dirent.h would be great if I needed to analyse information about
directories but since I don't need that functionality (and I have
already used it in the past) it is a rather pointless suggestion.
P
Paul
Chicken said:
Does the language need to be C ?
Paul
B
BGB
yep...
a JS/ES/... analogue would be something like:
eval("setName(\""+name+"\");");
(not sure if similar also applies to PHP, would have to look into this).
where some clever entries in the name field can do all sorts of things...
so, it is a good indication for things like:
for something which prints/composes something, be sure to filter the
string (or "C-ify" it, where any uncertain characters are escaped);
for code which parses something, it is a good idea to check for and make
sure one has the intended type of token (as a poorly written parser can
have "interesting" effects when fed cleverly crafted code).
nevermind all the usual annoyances, like trying to avoid buffer-overflow
risks, ...
S
Stephen Sprunk
As I said, pipes are the general solution.
The source for all of those should be available, so you'd have to
figure out whether it'd be more optimal (for your specific needs) to
crib the logic and API calls to get the data you need directly rather
than using pipes and parsing the output. Maybe, maybe not.
Obviously, I could only respond to the specific example you gave.
S
N
Nobody
The lack of quoting/escaping is a bigger problem than the fixed buffer
size. Apart from the need to protect against interpretation by the shell,
"rm" will interpret the argument as an option if it begins with a dash.
Using a relative path to "rm" means that it may run something other than
/bin/rm.
And performance is several orders of magnitude worse than remove() or
unlink() (fork() and/or exec() can be particularly expensive).
At least system() usually does the right thing with respect to signals;
the situation for popen() is much more complex.
T
tom st denis
I like that you post. In case of a lull of NNTP activity you're
useful to check if I still have net access...
J
jacob navia
Le 31/07/12 23:55, tom st denis a écrit :
At least his posts are useful, contrary to yours!
At least his posts are useful, contrary to yours!
K
Kenny McCormack
Cal Dershowitz said:
As I said before, every other newsgroup and online forum (IME) has a simple
ethic of "If you can't (or won't) answer the question, then STFU!". If you
violate this norm, you are pretty much politely ignored. But (obviously),
here in CLC, no such norm exists (hence this post [the post I am writing
right now] is unassailably correct in context).
But the real, underlying, problem is that the current rulers of CLC have
usurped the name. That is, a newsgroup named comp.lang.c should be about C,
but they have changed it into comp.religion.c - but forgot to change the
name. It is as if someone (back around 1991) had been assigned the task of
filing the paperwork to setup (charter, whatever terminology you prefer) a
new newsgroup, but forgot to do so (maybe they went on vacation that week,
maybe they got sick - who can say?). So, in desperation, they (the
religious zealots) just setup shop (for their new idea of what a newsgroup
about C should be like) here in comp.lang.c.
--
(This discussion group is about C, ...)
Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch [sic] revelations of the childhood
traumas of the participants...
T
tom st denis
Given that you've hijacked CLC to talk about your super-duper
collections library [which has nothing to do with clc] I'll take that
for what it's worth. Nothing.
Tom
T
tom st denis
Why is it such a hard concept that clc is about the C language and
comp.unix.programmer is about programming applications in unix?
If you want to chat about the finer points of POSIX functionality/etc
then move on over to comp.unix.programmer.
In the real world this would be like you showing up at a football game
and complaining that there are no hockey fans around.
Tom
T
tom st denis
In theory "remove()" is more portable given that "rm" is a typical
*NIX command not found on [say] Windows.
Depends on what you want to do with the information and how you want
to present it. When I hit "read file" in nano it presents me with a
directory listing that is nicely formatted that I can walk through
with the arrow keys. Can't do that with "ls" ...
Except where the system doesn't have an "rm" command... And this code
snippet [though just an example] doesn't check the return code of
system. This code can also fail simply because it cannot start a
shell to run "rm" whereas remove() will fail for reasons more directly
related to failing to remove the damn file/directory.
Tom
J
Jorgen Grahn
We're talking about
Message-ID: <[email protected]>
You're right. The first part /did/ come across as rather aggressive
when I read it ... but it wasn't insulting, and that's better than the
average Usenet posting.
I think the tone of the postings that followed influenced my view of
the first one.
/Jorgen
K
Kenny McCormack
tom st denis said:
Wrong, as usual.
A closer analogy would be as if I showed up at a football game and was told
that I (and all the other hockey fans) had to go home, because we aren't
true, blue, football fans (because we happen to be fans of both sports).
T
tom st denis
Nobody is questioning your devotion to the C language. They're
questioning if you know the name on the door you walked through.
There is actually an entire usenet group devoted to programming
challenges with *NIX and it's not clc.
That's the thing I don't get about you. It's not like there is NO
PLACE for those sorts of questions you just choose to refuse to accept
the reality that you're in the wrong spot and then you post [regularly
I might add] over the course of YEARS about the great travesty that is
topicality.
And it's not even like the other [helpful] regulars are being
particularly rude or unhelpful they're just telling the posters that
there are better places to ask the questions which will likely get
more appropriate responses.
Tom
K
Keith Thompson
tom st denis said:
Please don't feed the troll.
T
tom st denis
Never hurts to check in once in a while and see if there is any
humanity behind the account.
Tom