Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #126166 > unrolled thread

understanding C issues in geany install

Back to article view | Back to comp.lang.c

Contents

  understanding C issues in geany install fred flintstone <fred@server.invalid> - 2018-02-01 11:55 -0800
    Re: understanding C issues in geany install Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-01 12:04 -0800
    Re: understanding C issues in geany install Keith Thompson <kst-u@mib.org> - 2018-02-01 12:19 -0800
      Re: understanding C issues in geany install Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-04 19:24 +0000
        Re: understanding C issues in geany install David Kleinecke <dkleinecke@gmail.com> - 2018-02-04 16:02 -0800
    Re: understanding C issues in geany install "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-01 15:39 -0500
      Re: understanding C issues in geany install fred flintstone <fred@server.invalid> - 2018-02-07 07:44 -0800
    Re: understanding C issues in geany install Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-02-01 16:08 -0700
    Re: understanding C issues in geany install gordonb.669da@burditt.org (Gordon Burditt) - 2018-02-05 20:56 -0600
    Re: understanding C issues in geany install John Bode <jfbode1029@gmail.com> - 2018-02-06 09:26 -0800
      Re: understanding C issues in geany install Keith Thompson <kst-u@mib.org> - 2018-02-06 12:36 -0800
      Re: understanding C issues in geany install "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-06 15:49 -0500
        Re: understanding C issues in geany install scott@slp53.sl.home (Scott Lurndal) - 2018-02-06 21:37 +0000

#126166 — understanding C issues in geany install

Hello NewsGroup,

I can't wrap my head around the C issues that crop up in installing 
geany. When I'm forced back to C, I feel like I've been stripped of my 
rank and sent to Siberia or even relapsed, but those are just feelings, 
and probably an ego manifestation. Quite simply, I've forgotten most of 
what I knew about C, as I would have been most engaged with it whilst on 
MS architecture. I have high hopes for geany, including porting it to 
windholes, so I can use the gf's laptop to script.

I found that the build environment played a huge role in getting code to 
work, and that I wouldn't be able to replicate the frequent posts on 
*nix architecture. The simple fact is, if you are posting C output, then 
it must have run on *some* implementation, so a detractor or an OS bigot 
can claim that it is "implementation-specific" and therefore OT. 
Eschewing MS, one has to be his own IT guy....

Enough with the prologue.

Q1) Does contemporary standard C have any defined relationship to the 
shell, from the point of view of C?

Running ./configure  ...
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p

Q2) What does -c entail in the above?

Q3) When I script, I write
mkdir -p boulder
, without really knowing why. Is there a place I can look at the C 
source of mkdir on my machine to ascertain why?

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.3 LTS
Release:	16.04
Codename:	xenial
$

checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E

Nothing crazy looking here. Do I gather correctly that g is an alias for 
gcc?

Also, curious how C 89 and 99 were made to gyve:
checking for gcc option to accept ISO C99... none needed

checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes

Again, cloudy about -c in this context.

Finally, I have one Big Question:

Does the C Programming Language, as defined by C99, define anything 
about the shells that surround it? It's alright if the answer is no; I 
just want to know what it is.

 From C's point of view, what is bash? Does bash have a standard it 
adheres to? Is that POSIX?

Thanks for your comment. It's nice to "see old faces." I won't stick 
around too long if you just answer my questions.
-- 
fred flintstone

[toc] | [next] | [standalone]

#126167

On Thursday, February 1, 2018 at 7:55:25 PM UTC, fred flintstone wrote:
> 
> Does the C Programming Language, as defined by C99, define anything 
> about the shells that surround it? It's alright if the answer is no; I 
> just want to know what it is.
> 
The shell sits "above" C, and the C standard can't really legislate
about it.

Unix shells like bash expand wildcards on the command line, then call
C programs with potentially long lists of file arguments. Windows
simply passes the wildcards to the C program. The upshot is that 
there are likely to be minor incompatibilities between what is
essentially the same command line tool on Windows and Unix.

However nothing is stopping you from  writing a Windows compatible
Unix shell. The shell isn't really a privileged program.

[toc] | [prev] | [next] | [standalone]

#126168

fred flintstone <fred@server.invalid> writes:
[...]
> Enough with the prologue.
>
> Q1) Does contemporary standard C have any defined relationship to the 
> shell, from the point of view of C?

No.  A shell is just a program (which may or may not be written in C).

> Running ./configure  ...
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
>
> Q2) What does -c entail in the above?

"man install" will answer that.  (On my system, it's ignored; apparently
it meant something in earlier versions.)

> Q3) When I script, I write
> mkdir -p boulder
> , without really knowing why. Is there a place I can look at the C 
> source of mkdir on my machine to ascertain why?

Looking at the source would frankly be a silly way to find out what
"mkdir -p" means.  Try "man mkdir".

> $ lsb_release -a
> No LSB modules are available.
> Distributor ID:	Ubuntu
> Description:	Ubuntu 16.04.3 LTS
> Release:	16.04
> Codename:	xenial
> $
>
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking whether gcc understands -c and -o together... yes
> checking dependency style of gcc... gcc3
> checking how to run the C preprocessor... gcc -E
>
> Nothing crazy looking here. Do I gather correctly that g is an alias for 
> gcc?

No.  If you're referring to "-g", that's an option that can be passed to
the gcc command.  It tells it to produce debugging information.  Again,
"man gcc" can tell you more.  "info gcc" shows the gcc documentation in
another form that's likely to be more complete (you might need to
install the "gcc-doc" package for that to work).

Incidentally, none of your questions so far are about the C language.

> Also, curious how C 89 and 99 were made to gyve:
> checking for gcc option to accept ISO C99... none needed
>
> checking if gcc static flag -static works... yes
> checking if gcc supports -c -o file.o... yes
> checking if gcc supports -c -o file.o... (cached) yes
>
> Again, cloudy about -c in this context.

Again, it's an option to the gcc command.

> Finally, I have one Big Question:
>
> Does the C Programming Language, as defined by C99, define anything 
> about the shells that surround it? It's alright if the answer is no; I 
> just want to know what it is.

No.

>  From C's point of view, what is bash? Does bash have a standard it 
> adheres to? Is that POSIX?

C says nothing about bash.  It's a program that happens to be written in
C.  "info bash" (if bash-doc is installed) will tell you about bash.

POSIX does impose some requirements on the behavior of the standard
shell; bash follows most of those requirements and adds some
bash-specific features.

[...]

comp.unix.programmer probably would have been a better place for most or
all of these questions.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#126264

On Thu, 2018-02-01, Keith Thompson wrote:
> fred flintstone <fred@server.invalid> writes:
> [...]
>> Enough with the prologue.
>>
>> Q1) Does contemporary standard C have any defined relationship to the 
>> shell, from the point of view of C?
>
> No.  A shell is just a program (which may or may not be written in C).

Unless you count

  int main(int argc, char** argv);

which (not accidentally) works well with how shells want to feed a
series of strings as parameters to programs, and expects a smallish
integer back.  And also stdin/stdout/stderr of course.

...
> Incidentally, none of your questions so far are about the C language.

He seems to want to install the Geany text editor/IDE on Ubuntu.
(A guy at work uses it; it's probably not a bad idea.)  It's unclear
to me though why he doesn't just do "apt-get install geany".

> comp.unix.programmer probably would have been a better place for most or
> all of these questions.

Yes.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#126281

On Sunday, February 4, 2018 at 11:24:22 AM UTC-8, Jorgen Grahn wrote:
> On Thu, 2018-02-01, Keith Thompson wrote:
> > fred flintstone <fred@server.invalid> writes:
> > [...]
> >> Enough with the prologue.
> >>
> >> Q1) Does contemporary standard C have any defined relationship to the 
> >> shell, from the point of view of C?
> >
> > No.  A shell is just a program (which may or may not be written in C).
> 
> Unless you count
> 
>   int main(int argc, char** argv);
> 
> which (not accidentally) works well with how shells want to feed a
> series of strings as parameters to programs, and expects a smallish
> integer back.  And also stdin/stdout/stderr of course.
> 
> ...
> > Incidentally, none of your questions so far are about the C language.
> 
> He seems to want to install the Geany text editor/IDE on Ubuntu.
> (A guy at work uses it; it's probably not a bad idea.)  It's unclear
> to me though why he doesn't just do "apt-get install geany".
 
I have Geany installed on Ubuntu but I don't use it much.
It works most of the time but is not completely reliable.
I didn't do anything fancy to install it.

[toc] | [prev] | [next] | [standalone]

#126169

On 02/01/2018 02:55 PM, fred flintstone wrote:
...
> Q1) Does contemporary standard C have any defined relationship to the
> shell, from the point of view of C?

"#include <stdlib.h>
int system(const char *string);

If string is a null pointer, the system function determines whether the 
host environment has a command processor. If string is not a null 
pointer, the system function passes the string pointed to by string to 
that command processor to be executed in a manner which the 
implementation shall document; this might then cause the program calling 
system to behave in a non-conforming manner or to terminate.

Returns
If the argument is a null pointer, the system function returns nonzero 
only if a command processor is available. If the argument is not a null 
pointer, and the system function does return, it returns an 
implementation-defined value." (7.22.4.8)

That is the only defined relationship between them.

Given the implementation-dependence of the behavior of system(), it's 
close to impossible to make any portable use of that function.

> Running ./configure  ...
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> 
> Q2) What does -c entail in the above?

That's a question about the install command; on a Unix-like system, if 
the man pages have been correctly installed, you should be able to get 
the answer by typing:

     man install

"man" in the name for the online user manual program. On the system I'm 
using right now, the man page indicates "install" ignores the -c option. 
This kind of thing happens if something that used to be optional has 
become standard, so there's no longer any need to have an option to make 
it happen. The option is still allowed, so people don't have to rewrite 
their build scripts, but it doesn't change anything.

> Q3) When I script, I write
> mkdir -p boulder
> , without really knowing why. Is there a place I can look at the C
> source of mkdir on my machine to ascertain why?

Possibly, but typing

     man mkdir

is a much simpler way to the get the answer:

"       -p, --parents
               no error if existing, make parent directories as needed"

What this means is that instead of typing:
     mkdir parent
     mkdir parent/child

you can type
     mkdir -p parent/child

And it will first create the parent directory, if necessary, and then 
parent/child. Without the -p option, it would look for a parent 
directory to place child in, not find it, and generate an error message. 
It is therefore never necessary to use -p unless there's at least one 
'/' in the pathname for the directory you want to create.

> $ lsb_release -a
> No LSB modules are available.
> Distributor ID:	Ubuntu
> Description:	Ubuntu 16.04.3 LTS
> Release:	16.04
> Codename:	xenial
> $
> 
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking whether gcc understands -c and -o together... yes
> checking dependency style of gcc... gcc3
> checking how to run the C preprocessor... gcc -E
> 
> Nothing crazy looking here. Do I gather correctly that g is an alias for
> gcc?

The only isolated g in the above output is on the following line:
 > checking whether gcc accepts -g... yes

That g is NOT an alias for gcc. It is part of -g, which is an option 
that gcc might or might not accept. You can get information about gcc by 
  typing:
     man gcc

If you type "/ -g ", man will search for the string " -g ". Hit "n" as 
needed to continue on to the next match. On my system, I had to hit "n" 
5 times to get to the correct description, which says:

"-g Produce debugging information in the operating system's native
            format (stabs, COFF, XCOFF, or DWARF 2).  GDB can work with
            this debugging information."

> Also, curious how C 89 and 99 were made to gyve:
> checking for gcc option to accept ISO C99... none needed
> 
> checking if gcc static flag -static works... yes
> checking if gcc supports -c -o file.o... yes
> checking if gcc supports -c -o file.o... (cached) yes
> 
> Again, cloudy about -c in this context.

In this case, -c is a option on the gcc command. from "man gcc":

"-c Compile or assemble the source files, but do not link.  The linking
            stage simply is not done.  The ultimate output is in the form
            of an object file for each source file."

> Finally, I have one Big Question:
> 
> Does the C Programming Language, as defined by C99, define anything
> about the shells that surround it? It's alright if the answer is no; I
> just want to know what it is.

No.

>   From C's point of view, what is bash?

Nothing. Such matters are outside the scope of the C standard.

> ... Does bash have a standard it
> adheres to? Is that POSIX?

See <https://en.wikipedia.org/wiki/Bash_(Unix_shell)>.

bash is a freeware replacement for the Bourne shell, sh. It's widely 
available on Linux and macOS platforms, and there's a Windows 10 
compatible version as well. sh is defined by a POSIX standard. Executing 
"bash -posix" makes it conform very closely to the POSIX requirements 
for sh.

[toc] | [prev] | [next] | [standalone]

#126405

On 02/01/2018 12:39 PM, James R. Kuyper wrote:
> On 02/01/2018 02:55 PM, fred flintstone wrote:
> ...
>> Q1) Does contemporary standard C have any defined relationship to the
>> shell, from the point of view of C?
> 
> "#include <stdlib.h>
> int system(const char *string);
> 
> If string is a null pointer, the system function determines whether the 
> host environment has a command processor. If string is not a null 
> pointer, the system function passes the string pointed to by string to 
> that command processor to be executed in a manner which the 
> implementation shall document; this might then cause the program calling 
> system to behave in a non-conforming manner or to terminate.
> 
> Returns
> If the argument is a null pointer, the system function returns nonzero 
> only if a command processor is available. If the argument is not a null 
> pointer, and the system function does return, it returns an 
> implementation-defined value." (7.22.4.8)
> 
> That is the only defined relationship between them.
> 
> Given the implementation-dependence of the behavior of system(), it's 
> close to impossible to make any portable use of that function.

ok
> 
>> Running ./configure  ...
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking whether build environment is sane... yes
>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>>
>> Q2) What does -c entail in the above?
> 
> That's a question about the install command; on a Unix-like system, if 
> the man pages have been correctly installed, you should be able to get 
> the answer by typing:
> 
>      man install
> 
> "man" in the name for the online user manual program. On the system I'm 
> using right now, the man page indicates "install" ignores the -c option. 
> This kind of thing happens if something that used to be optional has 
> become standard, so there's no longer any need to have an option to make 
> it happen. The option is still allowed, so people don't have to rewrite 
> their build scripts, but it doesn't change anything.

It didn't occur to me that I could "man install," where I find this:

    -c     (ignored)

> 
>> Q3) When I script, I write
>> mkdir -p boulder
>> , without really knowing why. Is there a place I can look at the C
>> source of mkdir on my machine to ascertain why?
> 
> Possibly, but typing
> 
>      man mkdir
> 
> is a much simpler way to the get the answer:
> 
> "       -p, --parents
>                no error if existing, make parent directories as needed"
> 
> What this means is that instead of typing:
>      mkdir parent
>      mkdir parent/child
> 
> you can type
>      mkdir -p parent/child
> 
> And it will first create the parent directory, if necessary, and then 
> parent/child. Without the -p option, it would look for a parent 
> directory to place child in, not find it, and generate an error message. 
> It is therefore never necessary to use -p unless there's at least one 
> '/' in the pathname for the directory you want to create.

Gotcha. I'd never quite figured this out.
> 
>> $ lsb_release -a
>> No LSB modules are available.
>> Distributor ID:    Ubuntu
>> Description:    Ubuntu 16.04.3 LTS
>> Release:    16.04
>> Codename:    xenial
>> $
>>
>> checking for gcc... gcc
>> checking whether the C compiler works... yes
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables...
>> checking whether we are cross compiling... no
>> checking for suffix of object files... o
>> checking whether we are using the GNU C compiler... yes
>> checking whether gcc accepts -g... yes
>> checking for gcc option to accept ISO C89... none needed
>> checking whether gcc understands -c and -o together... yes
>> checking dependency style of gcc... gcc3
>> checking how to run the C preprocessor... gcc -E
>>
>> Nothing crazy looking here. Do I gather correctly that g is an alias for
>> gcc?
> 
> The only isolated g in the above output is on the following line:
>  > checking whether gcc accepts -g... yes
> 
> That g is NOT an alias for gcc. It is part of -g, which is an option 
> that gcc might or might not accept. You can get information about gcc by 
>   typing:
>      man gcc
> 
> If you type "/ -g ", man will search for the string " -g ". Hit "n" as 
> needed to continue on to the next match. On my system, I had to hit "n" 
> 5 times to get to the correct description, which says:
> 
> "-g Produce debugging information in the operating system's native
>             format (stabs, COFF, XCOFF, or DWARF 2).  GDB can work with
>             this debugging information."
> 
>> Also, curious how C 89 and 99 were made to gyve:
>> checking for gcc option to accept ISO C99... none needed
>>
>> checking if gcc static flag -static works... yes
>> checking if gcc supports -c -o file.o... yes
>> checking if gcc supports -c -o file.o... (cached) yes
>>
>> Again, cloudy about -c in this context.
> 
> In this case, -c is a option on the gcc command. from "man gcc":
> 
> "-c Compile or assemble the source files, but do not link.  The linking
>             stage simply is not done.  The ultimate output is in the form
>             of an object file for each source file."

So -c has a different context here.
> 
>> Finally, I have one Big Question:
>>
>> Does the C Programming Language, as defined by C99, define anything
>> about the shells that surround it? It's alright if the answer is no; I
>> just want to know what it is.
> 
> No.
> 
>>   From C's point of view, what is bash?
> 
> Nothing. Such matters are outside the scope of the C standard.
> 
>> ... Does bash have a standard it
>> adheres to? Is that POSIX?
> 
> See <https://en.wikipedia.org/wiki/Bash_(Unix_shell)>.
> 
> bash is a freeware replacement for the Bourne shell, sh. It's widely 
> available on Linux and macOS platforms, and there's a Windows 10 
> compatible version as well. sh is defined by a POSIX standard. Executing 
> "bash -posix" makes it conform very closely to the POSIX requirements 
> for sh.

Alright, these were the answers I was looking for. It's very helpful for 
me to sort out which standard applies. This script:

https://github.com/TBlazer66/island/blob/master/1.repos.sh

aims to install geany on debian systems. I can get scripts to save now, 
but still cannot get them to conform to an indenting scheme, so these 
scripts are still super jagged.

Thanks all for comments,
-- 
fred flintstone

[toc] | [prev] | [next] | [standalone]

#126171

fred flintstone <fred@server.invalid> writes:

> Hello NewsGroup,
>
> I can't wrap my head around the C issues that crop up in installing
> geany. When I'm forced back to C, I feel like I've been stripped of my
> rank and sent to Siberia or even relapsed, but those are just
> feelings, and probably an ego manifestation. Quite simply, I've
> forgotten most of what I knew about C, as I would have been most
> engaged with it whilst on MS architecture. I have high hopes for
> geany, including porting it to windholes, so I can use the gf's laptop
> to script.
>
> I found that the build environment played a huge role in getting code
> to work, and that I wouldn't be able to replicate the frequent posts
> on *nix architecture. The simple fact is, if you are posting C output,
> then it must have run on *some* implementation, so a detractor or an
> OS bigot can claim that it is "implementation-specific" and therefore
> OT. Eschewing MS, one has to be his own IT guy....
>
> Enough with the prologue.
>
> Q1) Does contemporary standard C have any defined relationship to the
> shell, from the point of view of C?

C does not, however the build scripts run in the shell.

> Running ./configure  ...
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
>
> Q2) What does -c entail in the above?

% man install
<snip>
       -c     (ignored)
<snip>

Looks like no.

> Q3) When I script, I write
> mkdir -p boulder
> , without really knowing why. Is there a place I can look at the C
> source of mkdir on my machine to ascertain why?

You probably don't want to read the source for this; go to the man page

% man mkdir

       -p, --parents
              no error if existing, make parent directories as needed

So you're creating a directory named 'boulder'; if it's already there it
won't be an error

> $ lsb_release -a
> No LSB modules are available.
> Distributor ID:	Ubuntu
> Description:	Ubuntu 16.04.3 LTS
> Release:	16.04
> Codename:	xenial
> $
>
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking whether gcc understands -c and -o together... yes
> checking dependency style of gcc... gcc3
> checking how to run the C preprocessor... gcc -E
>
> Nothing crazy looking here. Do I gather correctly that g is an alias
> for gcc?

No, -g is an option that can be passed to gcc to make it put extra stuff
in the compiled code that will let you use debuggers.  It's checking and
seeing that, yes, gcc accepts that option.

> Also, curious how C 89 and 99 were made to gyve:
> checking for gcc option to accept ISO C99... none needed

I don't know what you mean here.

> checking if gcc static flag -static works... yes
> checking if gcc supports -c -o file.o... yes
> checking if gcc supports -c -o file.o... (cached) yes
>
> Again, cloudy about -c in this context.

The -c option to gcc says to create object code, but not to link it
together.  This is checking to see whether you can both do that and
assign a name to the object (.o) file with the -o option.

> Finally, I have one Big Question:
>
> Does the C Programming Language, as defined by C99, define anything
> about the shells that surround it? It's alright if the answer is no; I
> just want to know what it is.

No.

> From C's point of view, what is bash? Does bash have a standard it
> adheres to? Is that POSIX?

C itself doesn't care about bash -- but the build scripts need it.

I wouldn't be surprised if there were a standard that shells should
adhere to, but I don't know if there is one.

> Thanks for your comment. It's nice to "see old faces." I won't stick
> around too long if you just answer my questions.

[toc] | [prev] | [next] | [standalone]

#126316

> I can't wrap my head around the C issues that crop up in installing 

What C issues?  The meaning of options on programs that might
be written in C isn't really a C issue.

> geany. 

Is that a species of lizard?  

> Q1) Does contemporary standard C have any defined relationship to the 
> shell, from the point of view of C?

Were you expecting an answer of "third cousin, twice removed"?

The C standard mentions system(), which invokes *a* shell (well,
command interpreter.  It doesn't have to be a shell, however that's
defined.  And it doesn't have do even do anything at all.) There
are way too many shells to refer to *the* shell, much like referring
to *the* key on *the* keyboard (which is in *MY* house, you keep
your hands off it!).

> Running ./configure  ...
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> 
> Q2) What does -c entail in the above?

It's an option to the install program, one which seems
to be the default anyway.  -c as opposed to -C seems to
mean *DO* change the modification time even if the target
file already exists.

> Q3) When I script, I write
> mkdir -p boulder
> , without really knowing why. Is there a place I can look at the C 
> source of mkdir on my machine to ascertain why?

What do you not understand?  How to spell "bolder"?  What mkdir
does?  ("mkdir" stands for "make a directory").  What -p does (don't
complain if a directory already exists, and create any missing
directories in the path if needed).

When in doubt, read the *DOCUMENTATION*.  Resort to the source code
if the documentation doesn't exist or is confusing.  For something
fairly simple like what an option means, the documentation, in
this case manual pages,  is often sufficient.

mkdir() is a system call, so the actual work is done in the kernel,
which is where the source code you'd look at is.  But start at the
manual pages.

> $ lsb_release -a
> No LSB modules are available.

Least Significant Byte?  Linux System Benguin?   I have no idea what
a "LSB module" is.  It must be something Linux-specific I haven't
run into.

> Distributor ID: Ubuntu
> Description:    Ubuntu 16.04.3 LTS
> Release:        16.04
> Codename:       xenial
> $
> 
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking whether gcc understands -c and -o together... yes
> checking dependency style of gcc... gcc3
> checking how to run the C preprocessor... gcc -E
> 
> Nothing crazy looking here. Do I gather correctly that g is an alias for 
> gcc?

No.  It's a command-line OPTION to gcc, asking for debugging
information to be included in the output.

> Also, curious how C 89 and 99 were made to gyve:
> checking for gcc option to accept ISO C99... none needed

That just suggests that gcc's default mode may be sufficiently
good for the test program used to check this.  If you are curious,
look at the C program it uses to test this and see what it's
checking.  For example, there are ways to make a program that
is legal C89 and legal C99 using // comments but they come
up with different answers.  I hope that's not what the
script is checking.

In many cases, putting in C99 features in a C89 compiler doesn't
break the C89 rules, so a compiler can mostly do both.

> checking if gcc static flag -static works... yes
> checking if gcc supports -c -o file.o... yes
> checking if gcc supports -c -o file.o... (cached) yes
> 
> Again, cloudy about -c in this context.

If you intend to use the gcc compiler, learn how to invoke it.  -c
means "compile but don't link", common if what you're compiling is
one source file out of many for the whole program.

> Does the C Programming Language, as defined by C99, define anything 
> about the shells that surround it? 

Do you mean shells have WEAPONS (besides big pinchy lobster claws),
and they can surround people?

> It's alright if the answer is no; I 
> just want to know what it is.

Sort of.  The C standard says there is a command processor that
exists and can be invoked by system().  It doesn't say that it is
a "shell".  It doesn't give many details.  It doesn't have to do
anything at all.  Tandy's "tsh", which tried to emulate a TRSDOS
interface (unlike other shells called "tsh" which are completely
different) that many of their customers were used to and came with
their version of Xenix for the Model 16 / Tandy 6000 (early 1980's),
might even qualify.

> From C's point of view, what is bash? Does bash have a standard it 
> adheres to? Is that POSIX?

bash is a program that might be written in C.  I'm not sure how
closely it adheres to the POSIX standard for a shell - it's probably
fairly close.

[toc] | [prev] | [next] | [standalone]

#126337

On Thursday, February 1, 2018 at 1:55:25 PM UTC-6, fred flintstone wrote:
> Hello NewsGroup,
> 
> I can't wrap my head around the C issues that crop up in installing 
> geany. 

What issues?  I see questions about output from configure, but nothing about *issues*.
Is geany failing to build?  Is it failing to install?  

[snip]
> 
> Q1) Does contemporary standard C have any defined relationship to the 
> shell, from the point of view of C?
> 

No.  C makes very few assumptions about the environment in which a C program executes.
From the program's perspective, it doesn't know (or care) that you're invoking it from bash,
a DOS shell (CMD), a DCL session on VMS, whatever.  It matters whether you're running in 
a freestanding or hosted environment (if the program is invoked from a shell, then it's 
extremely likely that it's running in a hosted environment).  

> Running ./configure  ...
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> 
> Q2) What does -c entail in the above?

Well, the output from the configure script says "checking for BSD-compatible install",
so I'd initially assume the -c option enables some special BSD-ism.  

On my system at work (SLES-10), both "man install" and "info install" show that -c is ignored; it's still there for compatibility with older versions of Unix.  

> 
> Q3) When I script, I write
> mkdir -p boulder
> , without really knowing why. Is there a place I can look at the C 
> source of mkdir on my machine to ascertain why?
> 

Looking at source code is possibly the worst way to figure out what command options
are available and what they do.  Look at the man page, rather than the source: either use
"man mkdir" or "info mkdir".  

> $ lsb_release -a
> No LSB modules are available.
> Distributor ID:	Ubuntu
> Description:	Ubuntu 16.04.3 LTS
> Release:	16.04
> Codename:	xenial
> $
> 
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking whether gcc understands -c and -o together... yes
> checking dependency style of gcc... gcc3
> checking how to run the C preprocessor... gcc -E
> 
> Nothing crazy looking here. Do I gather correctly that g is an alias for 
> gcc?
>

No.  The -g flag tells gcc to generate debugging information.  "man gcc" or "info gcc" (be
prepared for several hours of reading).  
 
> Also, curious how C 89 and 99 were made to gyve:
> checking for gcc option to accept ISO C99... none needed
> 
> checking if gcc static flag -static works... yes
> checking if gcc supports -c -o file.o... yes
> checking if gcc supports -c -o file.o... (cached) yes
> 
> Again, cloudy about -c in this context.
> 

 -c is an option to gcc.  Again, use "man gcc" or "info gcc" to learn more.  

> Finally, I have one Big Question:
> 
> Does the C Programming Language, as defined by C99, define anything 
> about the shells that surround it? It's alright if the answer is no; I 
> just want to know what it is.
> 

No.

>  From C's point of view, what is bash? 

Just another execution environment.

> Does bash have a standard it  adheres to? Is that POSIX?

There is no standard for bash, or any other shell that I am aware of.  

> 

> Thanks for your comment. It's nice to "see old faces." I won't stick 
> around too long if you just answer my questions.
> -- 
> fred flintstone

[toc] | [prev] | [next] | [standalone]

#126343

John Bode <jfbode1029@gmail.com> writes:
> On Thursday, February 1, 2018 at 1:55:25 PM UTC-6, fred flintstone wrote:
[...]
>> Does bash have a standard it  adheres to? Is that POSIX?
>
> There is no standard for bash, or any other shell that I am aware of.  

POSIX includes a specification of how the shell behaves, and bash
follows it reasonably closely.

The rest of your information was already covered by previous responses.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#126344

On 02/06/2018 12:26 PM, John Bode wrote:
...
> There is no standard for bash, or any other shell that I am aware of.

The POSIX standard covers sh, the Bourne shell, and bash -posix conforms 
very closely to the POSIX standard for sh.

[toc] | [prev] | [next] | [standalone]

#126347

"James R. Kuyper" <jameskuyper@verizon.net> writes:
>On 02/06/2018 12:26 PM, John Bode wrote:
>...
>> There is no standard for bash, or any other shell that I am aware of.
>
>The POSIX standard covers sh, the Bourne shell, and bash -posix conforms 
>very closely to the POSIX standard for sh.

To be accurate, the POSIX standard was derived from David Korn's ksh, which
was a significant improvement on Steven Bourne's original shell, and significantly
more robust than the contemporaneous BSD C shell (which was not compatible with
the original bourne shell at all).

Bash is a mix of POSIX and GNU extensions, but for me, ksh is more useful
(particuarly around floating arithmetic).

e.g.

$ printf '%f\n' $(( 1.8 * 3.1415926 ))
5.654867

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web