I have a simple program that compiles in Windows (vs 2022 latest - 64 &
32 bit) but to run it I have to type the full name of the program plus
its extension (e.g. "program.exe") but other programs just run with name
only such as "program2" (no extension needed). The program is:
#include <stdio.h>

int main()
{ unsigned int num1 = 15;

printf("Value %u = %u\n", num1, num1);
printf("doubled num1 = %d\n", num1 << 1);
printf("ShiftFour num1 = %d\n", num1 << 4);

return 0;
}

Jack <invalid@invalid.net> writes:
> I have a simple program that compiles in Windows (vs 2022 latest - 64 &
> 32 bit) but to run it I have to type the full name of the program plus
> its extension (e.g. "program.exe") but other programs just run with name
> only such as "program2" (no extension needed). The program is:
> #include <stdio.h>
>
> int main()
> {
> unsigned int num1 = 15;
>
> printf("Value %u = %u\n", num1, num1);
> printf("doubled num1 = %d\n", num1 << 1);
> printf("ShiftFour num1 = %d\n", num1 << 4);
>
> return 0;
> }

There's nothing odd about that program. (Except that you should use %u"
rather than "%d" for the second and third printfs, but that's not the
cause of your problem.)

This is not a C issue. It probably has to do with the way Windows finds
a command when you type its name. Theree's probably something else in
your search path that matches the name "program".

If the executable is in your current directory (and you're running it
from a command prompt, or from PowerShell, or something similar), it's
best to explicitly specify the directory: `.\program` or `.\program.exe`
(on a Unix-like system it would be `./program`).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On 1/23/2023 10:07 PM, Keith Thompson wrote:
> Jack <invalid@invalid.net> writes:
>> I have a simple program that compiles in Windows (vs 2022 latest - 64 &
>> 32 bit) but to run it I have to type the full name of the program plus
>> its extension (e.g. "program.exe") but other programs just run with name
>> only such as "program2" (no extension needed). The program is:
>> #include <stdio.h>
>>
>> int main()
>> {
>> unsigned int num1 = 15;
>>
>> printf("Value %u = %u\n", num1, num1);
>> printf("doubled num1 = %d\n", num1 << 1);
>> printf("ShiftFour num1 = %d\n", num1 << 4);
>>
>> return 0;
>> }
>
> There's nothing odd about that program. (Except that you should use %u"
> rather than "%d" for the second and third printfs, but that's not the
> cause of your problem.)
>
> This is not a C issue. It probably has to do with the way Windows finds
> a command when you type its name. Theree's probably something else in
> your search path that matches the name "program".
>
> If the executable is in your current directory (and you're running it
> from a command prompt, or from PowerShell, or something similar), it's
> best to explicitly specify the directory: `.\program` or `.\program.exe`
> (on a Unix-like system it would be `./program`).
>

For some damn reason, I just thought about ChatGPT asking questions
here, looking to be corrected in order to train itself.

On 24/01/2023 06:07, Keith Thompson wrote:
>
> If the executable is in your current directory (and you're running it
> from a command prompt, or from PowerShell, or something similar), it's
> best to explicitly specify the directory: `.\program` or `.\program.exe`
> (on a Unix-like system it would be `./program`).
>

Yes it works by typing .\program but what amazes me is that why other
programs in the same folder runs just by typing "program"? What is so
special about running shift operator?

The same program compiled using gcc or clang runs like before. It must
be something in Visual Studio that stops running the program. I will see
if Microsoft developers can verify this. I will post the question on
their forum so somebody can try it.

Thanks for the suggestion.

Jack <invalid@invalid.net> writes:
> On 24/01/2023 06:07, Keith Thompson wrote:
>>
>> If the executable is in your current directory (and you're running it
>> from a command prompt, or from PowerShell, or something similar), it's
>> best to explicitly specify the directory: `.\program` or `.\program.exe`
>> (on a Unix-like system it would be `./program`).
>
> Yes it works by typing .\program but what amazes me is that why other
> programs in the same folder runs just by typing "program"? What is so
> special about running shift operator?
>
> The same program compiled using gcc or clang runs like before. It must
> be something in Visual Studio that stops running the program. I will see
> if Microsoft developers can verify this. I will post the question on
> their forum so somebody can try it.
>
> Thanks for the suggestion.

Is the name of the program literally "program"? When asking for help
with a problem, it's important to show *exactly* what you did. The
specific name of the executable matters. For example, if it's
"dir.exe", then typing "dir" will probably run the system's directory
listing command rather than your program; ".\dir" would execute your
program. If it's "btfsplk.exe", then there probably isn't a system
command with the same name.

When you type "foo" at a command prompt, the system searches your path
(%PATH% on Windows, $PATH on Unix-like systems) for an executable name
"foo" (or "foo.exe" or "foo.bat" et all on Windows). The current
directory is likely at the *end* of your search path.

It's very likely that your program has a name that happens to match an
existing command, and the system executes that existing command rather
than your program. You should get into the habit of typing ".\foo"
("./foo" on Unix-like systems) when running a program "foo" in the
current directory.

And you haven't told us how you're executing the program. cmd.exe?
PowerShell?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On 24/01/2023 20:10, Keith Thompson wrote:
> Jack <invalid@invalid.net> writes:
>> On 24/01/2023 06:07, Keith Thompson wrote:
>>> If the executable is in your current directory (and you're running it
>>> from a command prompt, or from PowerShell, or something similar), it's
>>> best to explicitly specify the directory: `.\program` or `.\program.exe`
>>> (on a Unix-like system it would be `./program`).
>> Yes it works by typing .\program but what amazes me is that why other
>> programs in the same folder runs just by typing "program"? What is so
>> special about running shift operator?
>>
>> The same program compiled using gcc or clang runs like before. It must
>> be something in Visual Studio that stops running the program. I will see
>> if Microsoft developers can verify this. I will post the question on
>> their forum so somebody can try it.
>>
>> Thanks for the suggestion.
> Is the name of the program literally "program"? When asking for help
> with a problem, it's important to show *exactly* what you did. The
> specific name of the executable matters. For example, if it's
> "dir.exe", then typing "dir" will probably run the system's directory
> listing command rather than your program; ".\dir" would execute your
> program. If it's "btfsplk.exe", then there probably isn't a system
> command with the same name.
>
> When you type "foo" at a command prompt, the system searches your path
> (%PATH% on Windows, $PATH on Unix-like systems) for an executable name
> "foo" (or "foo.exe" or "foo.bat" et all on Windows). The current
> directory is likely at the *end* of your search path.
>
> It's very likely that your program has a name that happens to match an
> existing command, and the system executes that existing command rather
> than your program. You should get into the habit of typing ".\foo"
> ("./foo" on Unix-like systems) when running a program "foo" in the
> current directory.
>
> And you haven't told us how you're executing the program. cmd.exe?
> PowerShell?
>

I am running from the same directory as the executable file. The name of
the program is "shift.exe". I used "program.exe" and "program" to
simplify the matter but obviously it created more questions.

On a windows system the OS first looks for the executable file in the
same folder as from where the cmd is run. In my case, I have a folder
called "E:\CmdLine\C_cpp" and the output is:

E:\CmdLine\C_Cpp>.\shift
Value 15 = 15
doubled num1 = 30
ShiftFour num1 = 240

When the same program is compiled in GCC or clang then I can run them
like so:

E:\CmdLine\C_Cpp>clang -o shift3.exe shift.c

E:\CmdLine\C_Cpp>shift3
Value 15 = 15
doubled num1 = 30
ShiftFour num1 = 240

shift3 is the executable file I created to avoid over writing the file
created in Visual Studio. The clang command is self explanatory, I hope.
GCC is almost the same except the file is called shift2.exe. I hope this
helps.

What I was looking for is for somebody to try on their machine using any
of the Visual studio they have - 2010, 2013, 2015, 2017, 2019 or 2022.

I am using Windows 11 so perhaps that might be the problem. I'll see if
Windows 10 has got the same problem for such a simple program!!

On 24/01/2023 21:34, Jack wrote:
>
> On a windows system the OS first looks for the executable file in the
> same folder as from where the cmd is run. In my case, I have a folder
> called "E:\CmdLine\C_cpp" and the output is:
>

That is not correct. In particular, in PowerShell, the current
directory is /not/ used unless it is explicitly added to your $PATH or
you write ".\shift" (or, I think, "./shift").

And in Windows 11, PowerShell is the default shell.

(I have locked my Windows machine to Win7, because I don't want MS to
screw it up and break my programs and compatibility with hardware - I
have a lot of weird software and hardware in my job. So my experience
with newer Windows is a bit limited. But I have seen this one catch
people out after their system "upgraded" from Win 10 to Win 11.)

On 2023-01-24, Jack <invalid@invalid.net> wrote:
> On 24/01/2023 20:10, Keith Thompson wrote:
>> It's very likely that your program has a name that happens to match an
>> existing command, and the system executes that existing command rather
>> than your program. You should get into the habit of typing ".\foo"
>> ("./foo" on Unix-like systems) when running a program "foo" in the
>> current directory.
>>
>> And you haven't told us how you're executing the program. cmd.exe?
>> PowerShell?
>
> I am running from the same directory as the executable file. The name of
> the program is "shift.exe". I used "program.exe" and "program" to
> simplify the matter but obviously it created more questions.

'shift' is an existing Windows command.
Type 'shift/?' (without the quotes) to see what it does.
Type 'path' (without the quotes) to check the contents of your PATH.

On 24/01/2023 20:51, David Brown wrote:
> On 24/01/2023 21:34, Jack wrote:
>>
>> On a windows system the OS first looks for the executable file in the
>> same folder as from where the cmd is run. In my case, I have a folder
>> called "E:\CmdLine\C_cpp" and the output is:
>>
>
> That is not correct.  In particular, in PowerShell, the current
> directory is /not/ used unless it is explicitly added to your $PATH or
> you write ".\shift" (or, I think, "./shift").
>
> And in Windows 11, PowerShell is the default shell.
>
> (I have locked my Windows machine to Win7, because I don't want MS to
> screw it up and break my programs and compatibility with hardware - I
> have a lot of weird software and hardware in my job. So my experience
> with newer Windows is a bit limited.  But I have seen this one catch
> people out after their system "upgraded" from Win 10 to Win 11.)
>

Let me clarify once again. I know Windows 11's default is PowerShell (in
fact it is called Terminal in 22H2). I also know that to launch a
program in Powershell or Terminal one has to to append with .\something.

However, from Powershell or Terminal, you can execute cmd prompt (this
is the old style cmd prompt used in Windows 10 and prior OS) by simply
typing cmd in the powershell or terminal window. When you do this then
you can start using old style commands like launching a program by
simply typing "NameOfProgram"  and it works.

With this particular program (this only and I stress this forcefully)
you can't type "shift" to launch it even in the command prompt. The
program "shift" is compiled in Visual Studio 2022 and 2010 (for test
purposes only). The same program can be compiled in GCC or Clang and the
executable works just fine by typing "shift2" or "shift3". But the
program compiled in VS doesn't run like this.

The names are different because I didn't want files to be over written.
The exe files are shift, shift2 and shift3.

Does this clarify my position.

I know how Windows 10 and Windows 11 works. I haven't tried running the
program in Windows 10 yet because the laptop is in my bedroom and I am
currently working in my study but I will try to run it on that machine
later today.

I hope people won't confuse the issue with powershell, terminal and all
that. That's all covered here (I hope). All I was hoping for is somebody
will try it on their Windows 10 or Windows 11 machine to see if it is
the same on their machine but most people here are running Linux
machines so clearly it was a mistake to post this here.

Keith Thompson suggested to run it as .\shift and it works (in cmd
prompt as well as Terminal/PowerShell window). My point was why this
particular program is so different that you have to do that. I can run
"hello" just like that without using .\hello even if the program is
compiled in Visual studio.

That is all I wanted to say.

On 24/01/2023 21:12, Ike Naar wrote:
> 'shift' is an existing Windows command.
> Type 'shift/?' (without the quotes) to see what it does.
> Type 'path' (without the quotes) to check the contents of your PATH.

YES. That's it. I didn't know about that conflict. By changing the file
to shift1 just worked.

Thank you Ike Naar. You saved me from tearing my hair out.

Jack <invalid@invalid.net> writes:
> On 24/01/2023 20:10, Keith Thompson wrote:
>> Jack <invalid@invalid.net> writes:
>>> On 24/01/2023 06:07, Keith Thompson wrote:
>>>> If the executable is in your current directory (and you're running it
>>>> from a command prompt, or from PowerShell, or something similar), it's
>>>> best to explicitly specify the directory: `.\program` or `.\program.exe`
>>>> (on a Unix-like system it would be `./program`).
>>> Yes it works by typing .\program but what amazes me is that why other
>>> programs in the same folder runs just by typing "program"? What is so
>>> special about running shift operator?
>>>
>>> The same program compiled using gcc or clang runs like before. It must
>>> be something in Visual Studio that stops running the program. I will see
>>> if Microsoft developers can verify this. I will post the question on
>>> their forum so somebody can try it.
>>>
>>> Thanks for the suggestion.
>> Is the name of the program literally "program"? When asking for help
>> with a problem, it's important to show *exactly* what you did. The
>> specific name of the executable matters. For example, if it's
>> "dir.exe", then typing "dir" will probably run the system's directory
>> listing command rather than your program; ".\dir" would execute your
>> program. If it's "btfsplk.exe", then there probably isn't a system
>> command with the same name.
>>
>> When you type "foo" at a command prompt, the system searches your path
>> (%PATH% on Windows, $PATH on Unix-like systems) for an executable name
>> "foo" (or "foo.exe" or "foo.bat" et all on Windows). The current
>> directory is likely at the *end* of your search path.
>>
>> It's very likely that your program has a name that happens to match an
>> existing command, and the system executes that existing command rather
>> than your program. You should get into the habit of typing ".\foo"
>> ("./foo" on Unix-like systems) when running a program "foo" in the
>> current directory.
>>
>> And you haven't told us how you're executing the program. cmd.exe?
>> PowerShell?
>
> I am running from the same directory as the executable file. The name of
> the program is "shift.exe". I used "program.exe" and "program" to
> simplify the matter but obviously it created more questions.

You didn't answer my question, but you appear to be running cmd.exe, not
PowerShell.

> On a windows system the OS first looks for the executable file in the
> same folder as from where the cmd is run.

That does not appear to be correct. On my Windowss 10 system, %PATH%
ends with a semicolon, which if I understand correctly means that it
searchs the current directory *last*.

> In my case, I have a folder
> called "E:\CmdLine\C_cpp" and the output is:
>
> E:\CmdLine\C_Cpp>.\shift
> Value 15 = 15
> doubled num1 = 30
> ShiftFour num1 = 240
>
> When the same program is compiled in GCC or clang then I can run them
> like so:
>
> E:\CmdLine\C_Cpp>clang -o shift3.exe shift.c
>
> E:\CmdLine\C_Cpp>shift3
> Value 15 = 15
> doubled num1 = 30
> ShiftFour num1 = 240
>
> shift3 is the executable file I created to avoid over writing the file
> created in Visual Studio. The clang command is self explanatory, I hope.
> GCC is almost the same except the file is called shift2.exe. I hope this
> helps.

This has nothing to do with which compiler you're using, or even which
language you're using. It's entirely about *the name of the
executable file*.

"shift" is a built-in command in cmd.exe (and not in PowerShell). If
you type "shift" at a prompt, it will execute that built-in command
without searching %PATH%. There is no system-provided "shift.exe".
(Type "shift /?" for more information on the built-in "shift" command.)

Typing "shift.exe" without the leading ".\" should also run your
program, since the built-in "shift" command doesn't have a ".exe"
suffix. But I don't recommend that solution, since you'll still have
the same problem if you have an executable whose name matches the name
of a system executable in your path.

When you compiled with gcc or clang *and used a different name for the
executable*, the behavior changed, because there is no built-in command
or system-provided executable named "shift3" or "shift3.exe".

Again, this has nothing to do with C; it's only about the name of your
executable. And you can completely avoid this issue by cultivating the
habit of preceding the name of an executable in the current directory
with ".\".

(On Unix-like systems, it's generally recommended to remove ".", the
current directory, from your search path, precisely to avoid this kind
of problem. It's probably a good idea to do the same on Windows, but
the system default is to have the current directory at the end of
%PATH%.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On 24/01/2023 22:21, Jack wrote:
> On 24/01/2023 20:51, David Brown wrote:
>> On 24/01/2023 21:34, Jack wrote:
>>>
>>> On a windows system the OS first looks for the executable file in the
>>> same folder as from where the cmd is run. In my case, I have a folder
>>> called "E:\CmdLine\C_cpp" and the output is:
>>>
>>
>> That is not correct.  In particular, in PowerShell, the current
>> directory is /not/ used unless it is explicitly added to your $PATH or
>> you write ".\shift" (or, I think, "./shift").
>>
>> And in Windows 11, PowerShell is the default shell.
>>
>> (I have locked my Windows machine to Win7, because I don't want MS to
>> screw it up and break my programs and compatibility with hardware - I
>> have a lot of weird software and hardware in my job. So my experience
>> with newer Windows is a bit limited.  But I have seen this one catch
>> people out after their system "upgraded" from Win 10 to Win 11.)
>>
>
> Let me clarify once again. I know Windows 11's default is PowerShell (in
> fact it is called Terminal in 22H2). I also know that to launch a
> program in Powershell or Terminal one has to to append with .\something.
>
> However, from Powershell or Terminal, you can execute cmd prompt (this
> is the old style cmd prompt used in Windows 10 and prior OS) by simply
> typing cmd in the powershell or terminal window. When you do this then
> you can start using old style commands like launching a program by
> simply typing "NameOfProgram"  and it works.
>
> With this particular program (this only and I stress this forcefully)
> you can't type "shift" to launch it even in the command prompt. The
> program "shift" is compiled in Visual Studio 2022 and 2010 (for test
> purposes only). The same program can be compiled in GCC or Clang and the
> executable works just fine by typing "shift2" or "shift3". But the
> program compiled in VS doesn't run like this.
>
> The names are different because I didn't want files to be over written.
> The exe files are shift, shift2 and shift3.
>
> Does this clarify my position.
>
> I know how Windows 10 and Windows 11 works. I haven't tried running the
> program in Windows 10 yet because the laptop is in my bedroom and I am
> currently working in my study but I will try to run it on that machine
> later today.
>
> I hope people won't confuse the issue with powershell, terminal and all
> that. That's all covered here (I hope). All I was hoping for is somebody
> will try it on their Windows 10 or Windows 11 machine to see if it is
> the same on their machine but most people here are running Linux
> machines so clearly it was a mistake to post this here.
>
> Keith Thompson suggested to run it as .\shift and it works (in cmd
> prompt as well as Terminal/PowerShell window). My point was why this
> particular program is so different that you have to do that. I can run
> "hello" just like that without using .\hello even if the program is
> compiled in Visual studio.
>
> That is all I wanted to say.
>

We are just trying to get information about exactly what you are doing
here - without asking, we have no way of knowing whether you are an
experienced user, a newbie. We don't know if you are using PowerShell,
or cmd, or msys2 bash, without asking. I can't promise an answer even
if you give all the details, but it is at least a bit more likely.

There is no reason to suppose that the contents of the C program will
have the slightest influence on what you must type to start it. The
shell will have an influence, as will the path environment variable.
The compiler should not make a difference, and I don't believe it will
matter if it is a 32-bit or 64-bit executable. I am not an MSVC user -
is it possible that it has generated some special kind of file, rather
than a normal executable?

Yes, a lot of people here use Linux - it is common for developers who
have a choice for their OS. But there are plenty who work with Windows
too. (I do have a Windows machine, but my development work is primarily
on Linux.)

Jack <invalid@invalid.net> writes:
> On 24/01/2023 06:07, Keith Thompson wrote:
>>
>> If the executable is in your current directory (and you're running it
>> from a command prompt, or from PowerShell, or something similar), it's
>> best to explicitly specify the directory: `.\program` or `.\program.exe`
>> (on a Unix-like system it would be `./program`).
>>
>
> Yes it works by typing .\program but what amazes me is that why other
> programs in the same folder runs just by typing "program"? What is so
> special about running shift operator?

You have not demonstrated the problem is anything to do with the
shift operator, so you cannot make that assertion.

This is something OS specific. It might be something to do with your
PATH, and whether '.' is in it:
https://www.shellhacks.com/windows-cmd-path-variable-add-to-path-echo-path/
But you'll get the best help in a forum dedicated to your OS, I
repeat, this has nothing to do with C.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

Phil Carmody <pc+usenet@asdf.org> writes:
> Jack <invalid@invalid.net> writes:
>> On 24/01/2023 06:07, Keith Thompson wrote:
>>>
>>> If the executable is in your current directory (and you're running it
>>> from a command prompt, or from PowerShell, or something similar), it's
>>> best to explicitly specify the directory: `.\program` or `.\program.exe`
>>> (on a Unix-like system it would be `./program`).
>>>
>>
>> Yes it works by typing .\program but what amazes me is that why other
>> programs in the same folder runs just by typing "program"? What is so
>> special about running shift operator?
>
> You have not demonstrated the problem is anything to do with the
> shift operator, so you cannot make that assertion.

See the rather long followup I posted yesterday. I'm convinced that the
problem is caused specifically by the fact that the OP's program is
named "shift", which is a builtin command in the Windows command shell.

> This is something OS specific. It might be something to do with your
> PATH, and whether '.' is in it:
> https://www.shellhacks.com/windows-cmd-path-variable-add-to-path-echo-path/
> But you'll get the best help in a forum dedicated to your OS, I
> repeat, this has nothing to do with C.

Agreed. The OP was not unreasonable in posting here initially, but it's
been clear for a while that this is not a C issue (and I might be
justifiably criticized for discussing it here).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On 24/01/2023 21:28, Jack wrote:
> On 24/01/2023 21:12, Ike Naar wrote:
>> 'shift' is an existing Windows command.
>> Type 'shift/?' (without the quotes) to see what it does.
>> Type 'path' (without the quotes) to check the contents of your PATH.
>
> YES. That's it. I didn't know about that conflict. By changing the file
> to shift1 just worked.
>
> Thank you Ike Naar. You saved me from tearing my hair out.
>
For next time I'd point out that in your original post you said that
your program was called "program.exe". If you'd said "shift.exe" in the
first place you'd have got a quicker answer.

It can be important to be accurate about these things.

Andy

In article <trjsdo$1j6vk$3@dont-email.me>,
Vir Campestris <vir.campestris@invalid.invalid> wrote:
....
>For next time I'd point out that in your original post you said that
>your program was called "program.exe". If you'd said "shift.exe" in the
>first place you'd have got a quicker answer.
>
>It can be important to be accurate about these things.

I assumed that the post was intended as a quiz. I.e., for what value(s)
of "program" will this fail? (Or, "How can this happen?")

>Andy

Is it "Andy" or "Vic" ?

--
Modern Conservative: Someone who can take time out from demanding more
flag burning laws, more abortion laws, more drug laws, more obscenity
laws, and more police authority to make warrantless arrests to remind
us that we need to "get the government off our backs".

On Fri, 03 Feb 2023 21:06:25 +0000, Kenny McCormack wrote:

> In article <trjsdo$1j6vk$3@dont-email.me>,
> Vir Campestris <vir.campestris@invalid.invalid> wrote:
> ...
>>For next time I'd point out that in your original post you said that
>>your program was called "program.exe". If you'd said "shift.exe" in the
>>first place you'd have got a quicker answer.
>>
>>It can be important to be accurate about these things.
>
> I assumed that the post was intended as a quiz. I.e., for what value(s)
> of "program" will this fail? (Or, "How can this happen?")
>
>>Andy
>
> Is it "Andy" or "Vic" ?

Probably "Andy" (Where did you get "Vic" from?)

"Vir Campestris" looks to be his nom-de-usenet; it looks to be
Latin for "Man of the Plains"

--
Lew Pitcher
"In Skills We Trust"

In article <trk17v$1h746$1@dont-email.me>,
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
....
>> Is it "Andy" or "Vic" ?
>
>Probably "Andy" (Where did you get "Vic" from?)

Oops. I guess I misread "Vir" as "Vic".

>"Vir Campestris" looks to be his nom-de-usenet; it looks to be
>Latin for "Man of the Plains"

Interesting. Thanks.

Still, it is a little odd to sign your post with your real name (or
something which at appears to be such) when using a nym at the "top level"
of the post.

Nothing wrong with it, of course, just odd. (I note that some people on
this and other newsgroups get bent if you use the word "odd" without also
giving a citation to the appropriate standards document showing why the
thing you've referred to as "odd" is in fact a violation of said standards
document.) In fact, if I stated that the number 3 was "odd", they'd want
an appropriate citation.

--

First of all, I do not appreciate your playing stupid here at all.

- Thomas 'PointedEars' Lahn -

On 03/02/2023 22:18, Lew Pitcher wrote:
>
> Probably "Andy" (Where did you get "Vic" from?)
>
> "Vir Campestris" looks to be his nom-de-usenet; it looks to be
> Latin for "Man of the Plains"
>
.... or possibly fields. Well done that man! It's often found in the
binomial name of flowers.

You'll also find me in cam.misc, and Cambridgeshire is pretty flat.

Andy