why does this happen?

[Huge]

There *is* such a thing as taking dogma too far, you know. At some
point, a little common sense needs to walk into the room.

When GCC creates an executable, you don't have to chmod +x it as a
separate step - the compiler does it for you.

GCC's function is to create executables. It is not an editors function to
create executables.

 

[Peter J. Holzer]

No. What Peter is saying is that it would not be unreasonable for an
editor's save-as function to behave like cp -p, rather than plain cp.

No, what I'm saying is that it would not be unreasonable for an editor's
save-as function to behave like plain cp, rather than always using mode
0666 (minus umask, but that's a function of the OS, not the editor).

Oh, and since some people here are touting the security card: The
current behaviour can be seen as a security risk, too: If you open a
file which is readable only by the group (or even only by the owner) and
you save it it, you might not expect that the new file is
world-readable and accidentally divulge confidential information.

hp

 

[Peter J. Holzer]

Tell that to the Emacs people. Or the Vim people for that matter.

GCC's function is to create executables. It is not an editors function to
create executables.

In many cases it is. Scripts are executables, and they are almost always
created with an editor.

hp

 

[Eric Pozharski]

Oh, and since some people here are touting the security card: The
current behaviour can be seen as a security risk, too: If you open a
file which is readable only by the group (or even only by the owner)
and you save it it, you might not expect that the new file is
world-readable and accidentally divulge confidential information.

(btw, who's that "you"? I observe at least two security mornos here.)
Anyway, if a file contains sensitive information than one *creating*
such must set permissions correctly anyway. And one must not rely on
features of tools in use. Permissions must be verified after "cp"
either, mustn't they?

 

[Peter J. Holzer]

(btw, who's that "you"? I observe at least two security mornos here.)

"You" is the impersonal you, not any specific contributor to this
thread.

Anyway, if a file contains sensitive information than one *creating*
such must set permissions correctly anyway. And one must not rely on
features of tools in use. Permissions must be verified after "cp"
either, mustn't they?

Yes. If you've been bitten often enough by the behaviour of Unix tools,
you learn to check these things. For example, one problem with "cp" is
that it doesn't set the group explicitely, so you may wind up with a
copy which has the group bits set correctly but for the wrong group.

There is also the problem that if you copy a file from one directory to
the other there are at least two sane assumptions of what you want to
achieve:

1) You want to preserve the original permissions. If access to the
original file was restricted, it was for a reason, and the copy (having
the same contents) should have the same restrictions.

2) The permissions should be adapted to the new directory. You had a
reason to copy that file to a different location, and that reason
was most probably to make it available to the users who have access
to the target directory, so the permissions of the copy should
reflect that.

(our users frequently expect #2 and are confused if doesn't work that
way)

But the OP wasn't trying to do anything that fancy. He was opening a
script he had written himself and was saving it under a different name
in the same directory. I think it is very hard to argue that in this
case the permissions should be different than the original.

hp

 

[Jürgen Exner]

There is also the problem that if you copy a file from one directory to
the other there are at least two sane assumptions of what you want to
achieve:

1) You want to preserve the original permissions. If access to the
original file was restricted, it was for a reason, and the copy (having
the same contents) should have the same restrictions.

I disagree. One of the most frequent reasons to copy a file is to create
a private copy which can be amended and modified by me, no matter that
the original was owned by someone else and naturally write protected.

jue

 

[Ted Zlatanov]

JE> I disagree. One of the most frequent reasons to copy a file is to create
JE> a private copy which can be amended and modified by me, no matter that
JE> the original was owned by someone else and naturally write protected.

I think the obvious conclusion from all this is "it depends on what the
user wants" and thus it should be up to the user as an editor option,
ideally conditional by file name or at least extension.

Explicitly setting permissions bypasses the umask, the most fundamental
safeguard for file creation. In a shared system you always want a
restrictive umask, for instance. So again "it depends."

It's pretty easy to do this kind of conditional logic in Emacs Lisp.
Most regular editors, including Eclipse, don't have that kind of
flexibility.

Ted

 

[Eric Pozharski]

"You" is the impersonal you, not any specific contributor to this
thread.
Thanks.

*SKIP*
But the OP wasn't trying to do anything that fancy. He was opening a
script he had written himself and was saving it under a different name
in the same directory. I think it is very hard to argue that in this
case the permissions should be different than the original.

Exactly. I think, that I would probably welcome 'cp' being more
restrictive. I'm regularly bitten by 'patch' unwilling to patch
unwritable files in just extracted tar-ball. And that makes sense for
me (on both sides of a problem). However all that clash is about other
thing.

I believe that OP has came from toy-OS world, where suffix bears meaning
of executability. All of a sudden it's irrelevant on that side of the
fence. And now there're GUI-addicts who scream "Let's Save-As make just
written files executable".

In fact, I don't have a clear understanding what that Save-As thingy is.
I have ':w' (writes the buffer back), ':w >>filename' (writes the buffer
with other filename), and ':w !cmd' (pipes the buffer to command).
Which one is Save-As? All of them are ':write' for me.

GUI-addicts are boring.

 

[Eric Pozharski]

Hello newsgroups,

What a fscking troll you are.

*CUT*

 

[Peter J. Holzer]

I disagree. One of the most frequent reasons to copy a file is to create
a private copy which can be amended and modified by me,

That's why I wrote that there are "at least two sane assumptions". Your
reason is the second reason I explicitely mentioned, but which you
didn't quote. Did you remove it on purpose just so that you could
disagree or were you just unable to read the third short paragraph
before hitting the followup key?

hp

 

[Peter J. Holzer]

In fact, I don't have a clear understanding what that Save-As thingy is.
I have ':w' (writes the buffer back), ':w >>filename' (writes the buffer
with other filename), and ':w !cmd' (pipes the buffer to command).
Which one is Save-As? All of them are ':write' for me.

You forgot ':w filename', which is likely what the OP meant if he's
using a vi clone. If he's using vim in particular, he might have meant
':saveas filename' which is like ':w filename' followed by ':r filename'.

I was taking "Save as" (did he even use that term? I don't remember) as
a generic name for the editor's "save the current buffer under a
different file name" functionality. Since that functionality is common
to just about every editor I've used in the past 25 years I don't see
much value in bringing editor-specific commands into the discussion.

hp

 

[Jürgen Exner]

That's why I wrote that there are "at least two sane assumptions". Your
reason is the second reason I explicitely mentioned, but which you
didn't quote. Did you remove it on purpose just so that you could
disagree or were you just unable to read the third short paragraph
before hitting the followup key?

Neither, nor. I was unable to _understand_ what you were trying to say
in that paragraph.

jue

 

[Eric Pozharski]

You forgot ':w filename', which is likely what the OP meant if he's
using a vi clone. If he's using vim in particular, he might have meant
':saveas filename' which is like ':w filename' followed by ':r
filename'.

Me's corrected.

I was taking "Save as" (did he even use that term? I don't remember)

And this time, our prize goes toooooooooooooo... Uri!!!!

Message-ID: <[email protected]>

Fsck, 20 days before!

as a generic name for the editor's "save the current buffer under a
different file name" functionality. Since that functionality is common
to just about every editor I've used in the past 25 years I don't see
much value in bringing editor-specific commands into the discussion.

I'll better skip redescribing differences between ':w' and ':sav'. The
only thing I have to note is that the 2nd command isn't ':r' it's
':filetype detect'. And let me focus on this point.

I've thought a lot about that, and I've got to conclusion that Save-As
never makes files executable itself. (sorry for bringing back toy-OS
strawman again.) In the toy-OS file type comes with the suffix.
Whenever filetype is associated with some executable we could describe
such file as executable (someone could do that executing double-click).
Thus '*.txt' is kind of executable. However, for the purpose of this
quarrel, we'll stay from this. Let's say that if a file ends on laps of
'query.dll' (I've checked, '*.exe' ends there) (pity, I've forgot to
check where ends '*.dll') then it's executable, if not (there're many
other ways (such a legacy aware system, btw)) then it's not.

Thus, if someone Save-Ases as executable type with whatever editor
(really, whatever, that doesn't matter if that's notepad, oowriter or
edlin) then that user makes file executable *explicitly*. And vice
versa. However, if filetype isn't changed than just created file is
taken from the current filetype (most probably it's not executable).

I think, that if OP would have double-clicked the problematic file then,
most probably, it would be executed. There're mime-types for this,
aren't they? Thus it's the shell (probably whatever) that doesn't give
a fsck about mime-types and pays attention to executable-bit only. (I
don't think that shell couldn't be subverted into that pervert
behaviour. And you know, it most probably will be.)

However, (and I'll check that tomorrow) what if '*.bat' doesn't go to
'query.dll'? Then we have to agree that '*.txt' is executable either.

Shortly, my point is that executability doesn't spring from a corner.
It's set explicitly. Manually or not. Although what *is* executability
is in competence of shell. Being it concrete or GUI.

 

[Eric Pozharski]

However, (and I'll check that tomorrow) what if '*.bat' doesn't go to
'query.dll'? Then we have to agree that '*.txt' is executable either.

'*.txt' is executable. By definition. I've checked.