Hello,
assume foo/bar.h exists, and is included as '#include "bar.h"' in
foo/bar.c. `gcc -c foo/bar.c` will compile it fine (i.e. finds the
file). Is this a gcc extension or a C compiler standard feature that
foo/ will be searched without explicitly passing -Ifoo?
$ cat foo/bar.h
#define GOAL 1
$ cat foo/bar.c
#include <stdio.h>
#include "bar.h"
int main(void) {
printf("%d\n", GOAL);
return 0;
}
-`J'
--
26  2625 
Jan Engelhardt said:
Hello,
assume foo/bar.h exists, and is included as '#include "bar.h"' in
foo/bar.c. `gcc -c foo/bar.c` will compile it fine (i.e. finds the
file). Is this a gcc extension or a C compiler standard feature that
foo/ will be searched without explicitly passing -Ifoo?
The Standard does not specify the details of interfacing with an
implementation.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
"Jan Engelhardt" <je*****@linux01.gwdg.dewrote in message
news:Pi******************************@yvahk01.tjqt .qr...
Hello,
assume foo/bar.h exists, and is included as '#include "bar.h"' in
foo/bar.c. `gcc -c foo/bar.c` will compile it fine (i.e. finds the
file). Is this a gcc extension or a C compiler standard feature that
foo/ will be searched without explicitly passing -Ifoo?
$ cat foo/bar.h
#define GOAL 1
$ cat foo/bar.c
#include <stdio.h>
#include "bar.h"
int main(void) {
printf("%d\n", GOAL);
return 0;
}
-`J'
--
As a general rule if you include .h files in the same directory as the
associated .c file, they can be include with a simple quoted name.
All compilers have options for specifying default directories to search for
includes, and conventions vary.
-- www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
Malcolm said:
<snip>
All compilers have options for specifying default directories to search
for includes,
Some systems don't support the concept of "directory". Compilers on such
systems do not have options for specifying default directories to search
for "includes" (i.e. headers), since headers on such systems are not stored
in directories.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
"Richard Heathfield" <in*****@invalid.invalidwrote in message
Malcolm said:
<snip>
>All compilers have options for specifying default directories to search
for includes,
Some systems don't support the concept of "directory". Compilers on such
systems do not have options for specifying default directories to search
for "includes" (i.e. headers), since headers on such systems are not
stored
in directories.
There are plenty of computer systems without directories, but compilers
don't run on them. The compiler gets so angry at not having a directory to
sit in that it leaves and goes to another machine.
In other words, it becomes a cross compiler.
Some systems call directories "folders" for some impenetrable reason. Some
have weird ideas about hierachy. But they certainly have the concept of
"directory".
-- www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
"Malcolm" <re*******@btinternet.comwrote in message
news:pK******************************@bt.com...
"Richard Heathfield" <in*****@invalid.invalidwrote in message
Malcolm said:
<snip>
All compilers have options for specifying default directories to search
for includes,
Some systems don't support the concept of "directory". Compilers on such
systems do not have options for specifying default directories to search
for "includes" (i.e. headers), since headers on such systems are not
stored
in directories.
There are plenty of computer systems without directories, but compilers
don't run on them. The compiler gets so angry at not having a directory
to
sit in that it leaves and goes to another machine.
In other words, it becomes a cross compiler.
Some systems call directories "folders" for some impenetrable reason. Some
have weird ideas about hierachy. But they certainly have the concept of
"directory".
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
Wow, I compiled a lot of programs in several languages, naturally C being
one
of them, on an OS that had not concept of directories or folders. And I
assure
you it was not an obscure OS. LOL.
Malcolm wrote:
Some systems call directories "folders" for some impenetrable reason. Some
have weird ideas about hierachy. But they certainly have the concept of
"directory".
Well I agree that 99.9% of computers out there have OS's with the
concept of "directories". By which you probably mean the ability to
create multiple, named directories. And without the intervention of
the system operator.
But there have been plenty of OS's without that concept. Even OS's for
$12M computers. Most OS's before 1970 or so had either just one
directory for the whole system, or one system directory and one
directory per user, or one directory per physical volume, or
directories had to be created by system staff.
The concept of tree-structured directories didnt get popular until Unix
V6 and MSDOS 2.0 came out.
"Ancient_Hacker" <gr**@comcast.netwrote in message
>
Malcolm wrote:
>Some systems call directories "folders" for some impenetrable reason.
Some
have weird ideas about hierachy. But they certainly have the concept of
"directory".
Well I agree that 99.9% of computers out there have OS's with the
concept of "directories". By which you probably mean the ability to
create multiple, named directories. And without the intervention of
the system operator.
But there have been plenty of OS's without that concept. Even OS's for
$12M computers. Most OS's before 1970 or so had either just one
directory for the whole system, or one system directory and one
directory per user, or one directory per physical volume, or
directories had to be created by system staff.
The concept of tree-structured directories didnt get popular until Unix
V6 and MSDOS 2.0 came out.
I would say a directory is a group of files which does not include all that
are physically readable by the system.
I don't know of a system with a compiler that doesn't have directories.
However plenty of embedded systems don't have directories, even though they
may ahve backing store. Everything can be completely flat.
-- www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
>The concept of tree-structured directories didnt get popular until Unix
>V6 and MSDOS 2.0 came out.
I would say a directory is a group of files which does not include all that
are physically readable by the system.
I don't know of a system with a compiler that doesn't have directories.
CP/M 2.0 would qualify as not having directories, with the BDS C
Compiler. It wasn't ANSI C compliant (what was in the late 1970's?
Although this one didn't support floating point, at least the early
versions didn't). Unless you decided that each floppy had its
own directory and that constituted directory support, it didn't
support directories.
>However plenty of embedded systems don't have directories, even though they
may ahve backing store. Everything can be completely flat.
On Sat, 28 Oct 2006 23:27:21 +0100, "Malcolm"
<re*******@btinternet.comwrote:
>"Ancient_Hacker" <gr**@comcast.netwrote in message
>>
Malcolm wrote:
>>Some systems call directories "folders" for some impenetrable reason.
Some
have weird ideas about hierachy. But they certainly have the concept of
"directory".
And others have neither.
>>
Well I agree that 99.9% of computers out there have OS's with the
concept of "directories". By which you probably mean the ability to
create multiple, named directories. And without the intervention of
the system operator.
But there have been plenty of OS's without that concept. Even OS's for
$12M computers. Most OS's before 1970 or so had either just one
directory for the whole system, or one system directory and one
directory per user, or one directory per physical volume, or
directories had to be created by system staff.
The concept of tree-structured directories didnt get popular until Unix
V6 and MSDOS 2.0 came out.
I would say a directory is a group of files which does not include all that
are physically readable by the system.
I don't know of a system with a compiler that doesn't have directories.
the real world is not bound by the limitations of your knowledge. The
IBM MVS operating system, currently marketed under the name z/OS does
not have directories. And it doesn't use a cross compiler. It very
nicely generates native machine code for the S/370, S/390, Z8xx, and
Z9xx families of processors, the same hardware it executes on.
>However plenty of embedded systems don't have directories, even though they
may ahve backing store. Everything can be completely flat.
Remove del for email
In article <c8********************************@4ax.com>,
Barry Schwarz <sc******@doezl.netwrote:
>On Sat, 28 Oct 2006 23:27:21 +0100, "Malcolm"
<re*******@btinternet.comwrote:
>>I would say a directory is a group of files which does not include all that
are physically readable by the system.
I don't know of a system with a compiler that doesn't have directories.
>the real world is not bound by the limitations of your knowledge. The
IBM MVS operating system, currently marketed under the name z/OS does
not have directories.
My recollection from <mumbleyears ago is that it has logical disks
(not the right term, I know) that are often internally defined as
cylinder groups on physical disks, and that the logical disks can
be associated with a letter, and that a file designation by a user
is by a two part name (the second part of which may be associated
by tradition with a particular file "type") followed by the letter...
e.g., HELLO TEXT Z designating file HELLO TEXT on the cylinder group
currently associated with the letter Z.
Once a letter was associated with a cylinder group, the user could
request a listing of contents, with at least some level of wildcarding.
If the above is still the situation in z/OS then I would say that
z/OS -does- have directories within the definition given by Malcolm --
a grouping of files that does not include all that are physically
readable on the system. There might not be any master directory,
and other than drive A you might have to peak through people's
PROFILE to figure their default file set... and you'd miss all the dynamic
associations...
And it doesn't use a cross compiler. It very
>nicely generates native machine code for the S/370, S/390, Z8xx, and
Z9xx families of processors, the same hardware it executes on.
>>However plenty of embedded systems don't have directories, even though they
may ahve backing store. Everything can be completely flat.
Remove del for email
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)
In article <12*************@corp.supernews.com>,
Barry <ba****@nullhighstream.netwrote:
....
>Wow, I compiled a lot of programs in several languages, naturally C
being one of them, on an OS that had not concept of directories or
folders. And I assure you it was not an obscure OS. LOL.
MSDOS 1.0?
In article <zY******************************@bt.com>,
Malcolm <re*******@btinternet.comwrote:
....
>I would say a directory is a group of files which does not include all
that are physically readable by the system. I don't know of a system
with a compiler that doesn't have directories. However plenty of
embedded systems don't have directories, even though they may ahve
backing store. Everything can be completely flat.
The point is that none of that matters. The C standard doesn't require
it, so, as far as the troglodytes in this ng are concerned, it doesn't
exist.
Malcolm said:
"Richard Heathfield" <in*****@invalid.invalidwrote in message
>Malcolm said:
<snip>
>>All compilers have options for specifying default directories to search
for includes,
Some systems don't support the concept of "directory". Compilers on such
systems do not have options for specifying default directories to search
for "includes" (i.e. headers), since headers on such systems are not
stored
in directories.
There are plenty of computer systems without directories, but compilers
don't run on them.
MVS and VM/CMS are counter-examples. Undoubtedly there are others as well,
but those will suffice. Both are platforms for which ISO C implementations
exist, and neither has the concept of "directory".
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jan Engelhardt <je*****@linux01.gwdg.dewrites:
Hello,
assume foo/bar.h exists, and is included as '#include "bar.h"' in
foo/bar.c. `gcc -c foo/bar.c` will compile it fine (i.e. finds the
file). Is this a gcc extension or a C compiler standard feature that
foo/ will be searched without explicitly passing -Ifoo?
$ cat foo/bar.h
#define GOAL 1
$ cat foo/bar.c
#include <stdio.h>
#include "bar.h"
int main(void) {
printf("%d\n", GOAL);
return 0;
}
I've collected the behaviour of some C and C++ compilers on http://www.bourguet.org/cpp/include.html
If you know other behaviours, I'm interested to add them.
Yours,
--
Jean-Marc
Richard Heathfield wrote:
Malcolm said:
.... snip ...
>>
There are plenty of computer systems without directories, but
compilers don't run on them.
MVS and VM/CMS are counter-examples. Undoubtedly there are others
as well, but those will suffice. Both are platforms for which ISO
C implementations exist, and neither has the concept of "directory".
Another one, easily available to most, is CP/M-80. An easily
available simulator for many systems is at:
<http://www.schorn.ch/cpm/intro.html>
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
On Sun, 29 Oct 2006 00:27:38 +0000 (UTC), ro******@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote:
>In article <c8********************************@4ax.com>,
Barry Schwarz <sc******@doezl.netwrote:
>>On Sat, 28 Oct 2006 23:27:21 +0100, "Malcolm"
<re*******@btinternet.comwrote:
>>>I would say a directory is a group of files which does not include all that
are physically readable by the system.
I don't know of a system with a compiler that doesn't have directories.
>>the real world is not bound by the limitations of your knowledge. The
IBM MVS operating system, currently marketed under the name z/OS does
not have directories.
My recollection from <mumbleyears ago is that it has logical disks
(not the right term, I know) that are often internally defined as
cylinder groups on physical disks, and that the logical disks can
be associated with a letter, and that a file designation by a user
is by a two part name (the second part of which may be associated
by tradition with a particular file "type") followed by the letter...
e.g., HELLO TEXT Z designating file HELLO TEXT on the cylinder group
currently associated with the letter Z.
Once a letter was associated with a cylinder group, the user could
request a listing of contents, with at least some level of wildcarding.
If the above is still the situation in z/OS then I would say that
z/OS -does- have directories within the definition given by Malcolm --
a grouping of files that does not include all that are physically
readable on the system. There might not be any master directory,
and other than drive A you might have to peak through people's
PROFILE to figure their default file set... and you'd miss all the dynamic
associations...
Sorry but MVS has never had an association between a "logical disk"
and a letter. IBM has several different operation systems and a
different one may have something similar to what you describe.
Remove del for email
Gordon Burditt wrote:
The concept of tree-structured directories didnt get popular until Unix
V6 and MSDOS 2.0 came out.
I would say a directory is a group of files which does not include all that
are physically readable by the system.
I don't know of a system with a compiler that doesn't have directories.
CP/M 2.0 would qualify as not having directories, with the BDS C
Compiler. It wasn't ANSI C compliant (what was in the late 1970's?
Although this one didn't support floating point, at least the early
versions didn't). Unless you decided that each floppy had its
own directory and that constituted directory support, it didn't
support directories.
Can't recall if they were there in CP/M 2.0 or were only introduced for
2.2, but there were "user areas" that subdivided a logical drive into,
I believe it was, 16 numbered sub-areas. For the capacities of the day
(I paid $3,600 for a 10mb 8" Morrow hard disk drive circa 1980...), 16
subdirectories were plenty...
-leor
>
>I've collected the behaviour of some C and C++ compilers on
http://www.bourguet.org/cpp/include.html
If you know other behaviours, I'm interested to add them.
GCC should be put into the list where Visual C is listed, because that
is what I observed (#include "" in the directory of the file containing
the directive).
Have you tried SUNWspro yet?
-`J'
--
>The concept of tree-structured directories didnt get popular until Unix
>V6 and MSDOS 2.0 came out.
I would say a directory is a group of files which does not include all that
are physically readable by the system.
I don't know of a system with a compiler that doesn't have directories.
CP/M 2.0 would qualify as not having directories, with the BDS C
Compiler. It wasn't ANSI C compliant (what was in the late 1970's?
Although this one didn't support floating point, at least the early
versions didn't). Unless you decided that each floppy had its
own directory and that constituted directory support, it didn't
support directories.
Can't recall if they were there in CP/M 2.0 or were only introduced for
2.2, but there were "user areas" that subdivided a logical drive into,
I believe it was, 16 numbered sub-areas.
I'm reasonably sure they weren't present in CP/M 2.0, which is why
I said CP/M 2.0. The "sub-areas" didn't increase the number of
files you could fit on a floppy. "user 0" was special. A "user
0" file appeared in all "sub-areas", and a program running as "user
0" saw only "user 0" files.
And perhaps most important, there was no standardized way of
specifying "the config.h file in user area 5" by some kind of path
name. CP/M didn't provide a way of translating a text "path name"
into a FCB, so although it was possible to invent a syntax for such
a "path name", every application that wanted to use such a thing
had to be aware of the syntax or use a library that was, and it
wouldn't work for applications written before that feature was
introduced.
>For the capacities of the day
(I paid $3,600 for a 10mb 8" Morrow hard disk drive circa 1980...), 16
subdirectories were plenty...
-leor
Gordon Burditt wrote:
Can't recall if they were there in CP/M 2.0 or were only introduced for
2.2, but there were "user areas" that subdivided a logical drive into,
I believe it was, 16 numbered sub-areas.
I'm reasonably sure they weren't present in CP/M 2.0, which is why
I said CP/M 2.0. The "sub-areas" didn't increase the number of
files you could fit on a floppy. "user 0" was special. A "user
0" file appeared in all "sub-areas", and a program running as "user
0" saw only "user 0" files.
And perhaps most important, there was no standardized way of
specifying "the config.h file in user area 5" by some kind of path
name. CP/M didn't provide a way of translating a text "path name"
into a FCB, so although it was possible to invent a syntax for such
a "path name", every application that wanted to use such a thing
had to be aware of the syntax or use a library that was, and it
wouldn't work for applications written before that feature was
introduced.
Well, I did add user-area prefix recognition to the BDS C filename
syntax when user areas came out... so at least there was a "standard"
way of doing it under *that* platform...
-leor
Gordon Burditt wrote:
>
.... snip ...
>
And perhaps most important, there was no standardized way of
specifying "the config.h file in user area 5" by some kind of path
name. CP/M didn't provide a way of translating a text "path name"
into a FCB, so although it was possible to invent a syntax for such
a "path name", every application that wanted to use such a thing
had to be aware of the syntax or use a library that was, and it
wouldn't work for applications written before that feature was
introduced.
You obviously never used either ZCPR or my DOS+ system. Both had
DU addressing, whereby the file location could be described as
"B8:filename.typ", for example. My CCP+ (not sure about ZCPR) had
paths for executables, and (memory hazy) possibly for data.
CP/M2.2 documentation claimed that any user could execute programs
with the sys attribute in user area 0, but it didn't do it. DOS+
did. Together with the executables path, and the extension to
loading executables from COMMAND.LBR, this allowed much to be
packed into a small space and fairly good control of user
capabilities.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
>And perhaps most important, there was no standardized way of
>specifying "the config.h file in user area 5" by some kind of path
name. CP/M didn't provide a way of translating a text "path name"
into a FCB, so although it was possible to invent a syntax for such
a "path name", every application that wanted to use such a thing
had to be aware of the syntax or use a library that was, and it
wouldn't work for applications written before that feature was
introduced.
You obviously never used either ZCPR or my DOS+ system. Both had
DU addressing, whereby the file location could be described as
"B8:filename.typ", for example. My CCP+ (not sure about ZCPR) had
paths for executables, and (memory hazy) possibly for data.
That's great, now if only it could have been made to work for stuff
like the standard text editor, so you don't have the situation that
B8:filename.typ works on your system, fails with an error on some
other programs, or worse, since error-checking was never a strong
point of CP/M programs, quietly use B:filename.typ in the current
user area instead, or something else. There's a lot to be said for
consistency.
I remember seeing *at least*:
<drive><user>:filename.typ
<drive>:filename.typ;<user>
<drive>:filename.typ.<user>
and the user number wasn't always in decimal.
>CP/M2.2 documentation claimed that any user could execute programs
with the sys attribute in user area 0, but it didn't do it. DOS+
did. Together with the executables path, and the extension to
loading executables from COMMAND.LBR, this allowed much to be
packed into a small space and fairly good control of user
capabilities.
In article <jp********************************@4ax.com>,
Barry Schwarz <sc******@doezl.netwrote:
>Sorry but MVS has never had an association between a "logical disk"
and a letter. IBM has several different operation systems and a
different one may have something similar to what you describe.
Rechecking, it appears I was referring to CMS.
I very briefly investigated MVS last night; found a bunch of
unrelated T-shirt importation places, and lots of repetitions of
sites that didn't say anything much useful. I did find that
MVS's component specifiers are a convention rather than an
actual grouping.
What I was not able to determine within a reasonable time, though,
was exactly what an MVS catalog is. I could see that there was more
than one, including a critical "master catalog", and I could see
a few utilities such as LISTCAT that would list the catalog given
a project code.
It -appeared-, with the little hard data that I could find, that an MVS
catalog was arguably a "directory" within the meaning given by an
earlier poster. I did see a hint that catalogs did not really
organize the storage, and instead merely provided more convenient
ways to go between readable names and internal dataset serial numbers,
but if that is the case then it could be argued that a catalog entry
was akin to a traditional Unix directory entry, which merely associates
a name and an inode number with all the real action happening
at the inode level. None of this was really very clear in what I found.
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer
Walter Roberson wrote:
>
What I was not able to determine within a reasonable time, though,
was exactly what an MVS catalog is. I could see that there was more
than one, including a critical "master catalog", and I could see
a few utilities such as LISTCAT that would list the catalog given
a project code.
It -appeared-, with the little hard data that I could find, that an MVS
catalog was arguably a "directory" within the meaning given by an
earlier poster.
Not from an application programming perspective. You are barking up the
wrong tree if you are trying to find "directories" in MVS.
(hint #1: look up HFS).
(hint #2: http://www.redbooks.ibm.com/redbooks/SG245482.html read the
first paragraph of section 1.1 HFS Overview)
Barry Schwarz wrote:
>
the real world is not bound by the limitations of your knowledge. The
IBM MVS operating system, currently marketed under the name z/OS does
not have directories.
While true, you can, however, create HFS data sets that are organized
with a tree-like structure using directories via USS (Unix Systems
Services). From a C program, luckily, your file structure (whether it
is PDS, Physical Sequential, or VSAM or whatever) looks like a stream
and the details aren't necessary. If you are writing a program that
_needs_ to know these details then, it's off-topic here :o) (I am
pretty sure you know all this Barry. Sometimes MVS people forget about
USS in MVS.)
On 28 Oct 2006 15:20:20 -0700, "Ancient_Hacker" <gr**@comcast.net>
wrote:
<snip>
Well I agree that 99.9% of computers out there have OS's with the
concept of "directories". By which you probably mean the ability to
create multiple, named directories. And without the intervention of
the system operator.
But there have been plenty of OS's without that concept. Even OS's for
$12M computers. Most OS's before 1970 or so <snip>
The concept of tree-structured directories didnt get popular until Unix
V6 and MSDOS 2.0 came out.
MULTICS was definitely several years earlier; TOPS-20 was TTBOMR about
concurrent with first Unix, and TENEX several years earlier.
OS/360 had hierarchically organized _names_, stored centrally in a
system catalog not in separate directories, by the mid '60s. And it
was more widely used and known/taught than the others combined.
But if you mean 'popular' in the sense of used (directly) by large
numbers of people, that would indeed be MSDOS; those others ran on
systems an ordinary person couldn't afford.
But to Walter Roberson downthread, the S/370 et seq system with
"logical disk" with 1letter* 8char-filename 8char-filetype is _CMS_
(run under VM) NOT MVS or any other flavor of OS/* now z/OS.
(* Technically IIRC 1letter disk and optional 1digit mode, but the
latter is rarely needed or used.)
And although it's a debatable point of terminology, I would say that
any centralized metadata mapping names to storage (regions) is a
directory, including CMS, RT-11, and early CP/M or MSDOS; where
necessary I would call this a "one-level" or "fixed" directory in
contrast to "hierarchical" and/or "user-defined" directories. For a
truly nondirectory structure I would point to IBM partitioned data
sets (PDS); Unix (originally) "ar" and "tar" archives; and the alltime
classic, labelled magtapes. Note not ZIP; it has metadata both
distributed AND centralized, and so counts as directoried.
- David.Thompson1 at worldnet.att.net This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Charts |
last post by:
I recently upgraded development web server to Windows 2003. I have ASP file contains following line for include file
<!--#include File="../Include/adovbs.inc"--
This ASP file worked fine before....
|
by: tom pester |
last post by:
Hi,
Im new to php and have a background in asp. All the help is very much appreciated.
today I was using the include function in a file that itself gets included :
***************...
|
by: Intaek LIM |
last post by:
hi guys.
i just got a library for generating packets.
but, i can't compile the example source because of bad include path.
...
|
by: alex |
last post by:
Hi,
I've got a php script located at : http://localhost/browse/script.php
This script is "URL-rewrited" as http://localhost/welcome.htm
This script includes other scripts with the following...
|
by: cybervigilante |
last post by:
I can't seem to change the include path on my local winmachine no
matter what I do. It comes up as
includ_path .;C:\php5\pear in phpinfo() but there is no such file. I
installed the WAMP package...
|
by: dave6502 |
last post by:
Struggling newbe here, some of my #includes work, some dont. Is it
possible to list the include path ? (in BASH),
I have looked at the environmental variables (loads of them) but
cannot find a...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
| |
